Addition of "official" overlays brings possible collisions between different overlays' ebuilds. eix utility should provide support for performing a search for both local and remote overlays for specific ebuild so information about ebuild can be accessed easily. In addition, for those who develop their own overlays, such option may ease search for same ebuilds in other overlays and solve possible conflicts before they happen.
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.
