Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 144200 - eix tools should allow performing search in both local and remote overlays
Summary: eix tools should allow performing search in both local and remote overlays
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Third-Party Tools (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Martin Väth
Depends on:
Reported: 2006-08-17 06:52 UTC by Alex Bogak
Modified: 2006-09-01 04:01 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Alex Bogak 2006-08-17 06:52:39 UTC
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.
Comment 1 Stefan Schweizer (RETIRED) gentoo-dev 2006-08-17 15:27:56 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 :)
Comment 2 Martin Väth 2006-08-18 05:44:00 UTC
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...
Comment 3 Martin Väth 2006-08-18 05:59:51 UTC
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"
  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.
Comment 4 Martin Väth 2006-08-19 07:02:15 UTC
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.
Comment 5 Martin Väth 2006-09-01 04:01:16 UTC
Since eix-0.7.2 with remote support is now in the portage tree, I consider this bug as closed.