| 1 |
Am 22.07.2012 14:00, schrieb Nilesh Govindrajan: |
| 2 |
> I guess I'm missing some settings specific to this? I have 3 overlays |
| 3 |
> installed via layman, and this eix takes ridiculously long to index |
| 4 |
> through them, I don't know why. |
| 5 |
> |
| 6 |
> The portage tree is indexed quickly. |
| 7 |
> |
| 8 |
|
| 9 |
There is usually not much you can do there. This typically happens with |
| 10 |
overlays that contain no metadata cache. |
| 11 |
|
| 12 |
Look at your overlay directory into metadata/layout.conf. If it doesn't |
| 13 |
contain a "cache-formats" line you are probably out of luck since eix |
| 14 |
has to parse each ebuild. |
| 15 |
|
| 16 |
Read the section about CACHE_METHOD in `man eix` |
| 17 |
|
| 18 |
The default method for overlays is "parse|ebuild*" meaning that if there |
| 19 |
is a cache, it will be used and double-checked with a fast parser |
| 20 |
("parse"). If there is no cache, the parser will be used alone. If that |
| 21 |
does not give satisfying results (e.g. because variables are set in |
| 22 |
eclasses instead of ebuilds), the real ebuild parser (i.e. bash) will be |
| 23 |
used to parse them ("ebuild*"). |
| 24 |
|
| 25 |
The last step is probably what causes the delays. It also poses a |
| 26 |
security risk if you don't trust the ebuilds since you are basically |
| 27 |
executing them (although with limited permissions). |
| 28 |
|
| 29 |
Things might get better if they ever get libbash [1] finished. But don't |
| 30 |
hold your breath. |
| 31 |
|
| 32 |
If you need to update the eix cache on several systems, it might be |
| 33 |
faster to generate a cache on one machine and distribute it to all |
| 34 |
other. See `man egencache`. |
| 35 |
|
| 36 |
[1] http://qiaomuf.wordpress.com/2011/05/05/introduction-to-libbash/ |
| 37 |
|
| 38 |
Regards, |
| 39 |
Florian Philipp |
Archives