On Tue, Jun 28, 2011 at 03:43:21PM +1200, Kent Fredric wrote:
> A. Storing tag data in metadata.xml   ( package -> tag association )
> B. Developing a tool that aggregates the contents of metadata.xml to
> produce a cache for the data going the other way ( tag -> package )
> 
> People searching for packages that match a tag will thusly be able to
> read this cached data ( Our primary use case )  and people who want to
> know what tags a specific package have will read/augment metadata.xml
> 
> I Believe both these parts are required for the design to be successful.
> 
> However, both parts have a bit of bike-shedding involved in them,
> part A of the system requires changes to exisiting structures, and
> part A requires bike shedding about part B's format.
> 
> For the sake of simplicity, I'm ( and I believe others ) are simply
> suggesting we develop part B first.

It's sub hour or so to look at the existing `egencache 
--update-use-local-desc` (specifically GenUseLocalDesc class) and 
implement such a cache.  It's not hard.

Either way, if you want this, the part that will take time is 
integrating it into emerge itself for searching; now if you want to 
write that code twice, go nuts, but someone lazier would do both at 
the same time to make sure they structured the API so it could 
support in one pass, rather than deploying an API, than having to 
shoehorn the cpv argument in.

If people want it, cut a patch and post it for feedback either way- 
bearing in mind that from where I'm sitting, deploying it half-assed 
requiring people to maintain a bunch of text files isn't a viable 
option ;)

~brian