Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?

[Ned Ludd]

On Tue, 2008-11-25 at 16:31 -0800, Brian Harring wrote:
> On Tue, Nov 25, 2008 at 04:18:22PM -0800, Ned Ludd wrote:
> >
> > On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
> > > On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> > > > Given the following:
> > > > # qlist -Iv sys-apps/portage
> > > > sys-apps/portage-2.1.4.5
> > > >
> > > > How do I safely extract the "2.1.4.5"?
> > > >
> > > > (I don't necessarily need to use qlist. Just want to get the version of an
> > > > installed package within a bash script)
> > >
> > > This *really* should be folded into portageq offhand- it's the initial
> > > step towards shifting versionator logic (yet another standalone
> > > parser/comparison implementation) into the PM.
> > >
> > > Counter arguements?
> > > ~brian
> >
> > Yes. he said a bash script. portageq still takes a few seconds to load
> > and invokes far far to many instructions for very simple info.
> >
> > The 3 execve's I just posted are still faster than one portageq call.
> > So.. foo.c wins again. :p
>
> Curious, does qatom handle use deps?  Slot deps?  Plans to add
> repository deps (admittedly they've not landed)?

Nope. I'm sticking with EAPI=0 behaviorism's and the development of
those utils has pretty much stopped. Well I did slip in some :slot
handling a little while ago due to the syntax of the world file changing
a while back after being annoyed.

> The point of shifting it into portageq isn't speed based; it's to
> transfer responsibility for atom parsing from multiple authorities
> into a single one.

It's still a good idea to expend the functionality of portageq. But for
scripting from bash, reality wins as most everything python-portage
related falls a little short due to the sheer number of file i/o calls
python makes looking for files that might not pertain at all to the info
the user is after. Granted today it's a heck of a lot faster than it
used to be a few years ago when the loading problem was first noticed. 

> Besides, just because portageq is slow for heavy data ops doesn't mean
> it's going to be slow for doing simple atom splitting.  Quick test
> locally, cold cache pegs it at 3s- with minor use of snakeoil
> demandload that's likely halvable.
>
> ~brian


I'm all in favor of using the right tool for the task at hand whatever
that may be.