| 1 |
On Tue, Nov 25, 2008 at 04:18:22PM -0800, Ned Ludd wrote: |
| 2 |
> |
| 3 |
> On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote: |
| 4 |
> > On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote: |
| 5 |
> > > Given the following: |
| 6 |
> > > # qlist -Iv sys-apps/portage |
| 7 |
> > > sys-apps/portage-2.1.4.5 |
| 8 |
> > > |
| 9 |
> > > How do I safely extract the "2.1.4.5"? |
| 10 |
> > > |
| 11 |
> > > (I don't necessarily need to use qlist. Just want to get the version of an |
| 12 |
> > > installed package within a bash script) |
| 13 |
> > |
| 14 |
> > This *really* should be folded into portageq offhand- it's the initial |
| 15 |
> > step towards shifting versionator logic (yet another standalone |
| 16 |
> > parser/comparison implementation) into the PM. |
| 17 |
> > |
| 18 |
> > Counter arguements? |
| 19 |
> > ~brian |
| 20 |
> |
| 21 |
> Yes. he said a bash script. portageq still takes a few seconds to load |
| 22 |
> and invokes far far to many instructions for very simple info. |
| 23 |
> |
| 24 |
> The 3 execve's I just posted are still faster than one portageq call. |
| 25 |
> So.. foo.c wins again. :p |
| 26 |
|
| 27 |
Curious, does qatom handle use deps? Slot deps? Plans to add |
| 28 |
repository deps (admittedly they've not landed)? |
| 29 |
|
| 30 |
The point of shifting it into portageq isn't speed based; it's to |
| 31 |
transfer responsibility for atom parsing from multiple authorities |
| 32 |
into a single one. |
| 33 |
|
| 34 |
Besides, just because portageq is slow for heavy data ops doesn't mean |
| 35 |
it's going to be slow for doing simple atom splitting. Quick test |
| 36 |
locally, cold cache pegs it at 3s- with minor use of snakeoil |
| 37 |
demandload that's likely halvable. |
| 38 |
|
| 39 |
~brian |
Archives