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.
