1 |
On Tue, Nov 25, 2008 at 08:54:29PM -0800, Zac Medico wrote: |
2 |
> Ned Ludd wrote: |
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 |
> >> This *really* should be folded into portageq offhand- it's the initial |
14 |
> >> step towards shifting versionator logic (yet another standalone |
15 |
> >> parser/comparison implementation) into the PM. |
16 |
> >> |
17 |
> >> Counter arguements? |
18 |
> >> ~brian |
19 |
> > |
20 |
> > Yes. he said a bash script. portageq still takes a few seconds to load |
21 |
> > and invokes far far to many instructions for very simple info. |
22 |
> > |
23 |
> > The 3 execve's I just posted are still faster than one portageq call. |
24 |
> > So.. foo.c wins again. :p |
25 |
> |
26 |
> Well, I think portageq will be fine if it's limited to a small |
27 |
> number of calls. Here's a simple test, with portage-2.2_rc16: |
28 |
> |
29 |
> # time python -c "import portage.versions" |
30 |
> |
31 |
> real 0m0.141s |
32 |
> user 0m0.124s |
33 |
> sys 0m0.016s |
34 |
> |
35 |
> It's not so bad if it only has to be called a few times. For cases |
36 |
> where a large number need to be split, they could be processed in a |
37 |
> batch by a single portageq call, by either passing all the inputs in |
38 |
> as arguments or writing them to stdin. |
39 |
|
40 |
So.. eapi3 meanwhile? |
41 |
~brian |