Summary: | eix tools should allow performing search in both local and remote overlays | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Alex Bogak <djay> |
Component: | Third-Party Tools | Assignee: | Martin Väth <martin> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | enhancement | CC: | coldwind, genstef, martin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alex Bogak
2006-08-17 06:52:39 UTC
remote searching would require that an index be stored somewhere on the web with regular eix-diffs to update. Maybe autogenerated every day. What do you think Martin? Would that be possible/reasonable/doable to integrate? Server capacity is available enough, and of course it should be disabled by default for a start :) The first question is: How to get the diff's? The most reasonable way is to rsync the metadata directory. In such a case, eix must be able to use e.g. metadata information for just one specified overlay. I have written a patch for eix with which you can do this. The other thing is that you might want to fetch an eix-cache-file and just add the corresponding data to your database as the overlay. To do this, I have written a new cache method "eix" where you can specify an eix-cache file and an overlay to use. I have included both patches in eix' current svn trunk, but they are practically untested yet... I should perhaps explain the concept more precisely: If special eix-support should be provided, the overlay maintainer must provide either 1. a (properly filled) "metadata" directory (as the metadata directory of the main portage tree - I don't know how it is generated) or 2. an eix-cache-file (which might be generated with update-eix --exclude-overlay /usr/portage/ --exclude-overlay ...) Then the user can easily write a script which rsyncs the metadata directory or the eix-cache-file and which afterwards calls update-eix with a corresponding local variable ADD_CACHE_METHOD="path-to-overlay metadata" resp. ADD_CACHE_METHOD="path-to-overlay eix:path-to-eix-cache-file:0" Optionally (for perhaps faster processing), one could also add the value "/usr/portage/ eix" to ADD_CACHE_METHOD so that the main tree is re-read from the internal cache. Two important changes in the eix' new svn trunk concerning these features: 1. Some overlays might introduce new categories in a new profile/categories. In order to deal with such a case also, I introduced another cache method eix* which also adds the categories if needed, i.e. after downloading some eix-cache-file for the overlay (assuming such a file is provided by the maintainer of the overlay) into /tmp/cache.eix you can now e.g. use the command ADD_CACHE_METHOD="$(portageq portdir)/ eix remote-overlay eix*:/tmp/cache.eix" update-eix --add-overlay remote-overlay and you will afterwards see the full new overlay with eix as "remote-overlay". Of course, you can choose any other path instead of "remote-overlay" as well, e.g. "/usr/local/overlay". Note that this path need not exist, but if it is the path of another existing overlay, the data of /tmp/cache.eix would be taken instead of the "original" data. 2. I also changed the internal processing to speed up the handling of the new cache-methods "eix" and "eix*": Taking its own full cache as input for these cache-methods, update-eix now needs much less than a second for this step on my system. If there are problems with the patches or with my suggestion, re-open the bug. When I do not hear bug reports for a while, the patches will go into eix-0.6.5. Since eix-0.7.2 with remote support is now in the portage tree, I consider this bug as closed. |