| 1 |
On Tue, Jun 28, 2011 at 03:43:21PM +1200, Kent Fredric wrote: |
| 2 |
> A. Storing tag data in metadata.xml ( package -> tag association ) |
| 3 |
> B. Developing a tool that aggregates the contents of metadata.xml to |
| 4 |
> produce a cache for the data going the other way ( tag -> package ) |
| 5 |
> |
| 6 |
> People searching for packages that match a tag will thusly be able to |
| 7 |
> read this cached data ( Our primary use case ) and people who want to |
| 8 |
> know what tags a specific package have will read/augment metadata.xml |
| 9 |
> |
| 10 |
> I Believe both these parts are required for the design to be successful. |
| 11 |
> |
| 12 |
> However, both parts have a bit of bike-shedding involved in them, |
| 13 |
> part A of the system requires changes to exisiting structures, and |
| 14 |
> part A requires bike shedding about part B's format. |
| 15 |
> |
| 16 |
> For the sake of simplicity, I'm ( and I believe others ) are simply |
| 17 |
> suggesting we develop part B first. |
| 18 |
|
| 19 |
It's sub hour or so to look at the existing `egencache |
| 20 |
--update-use-local-desc` (specifically GenUseLocalDesc class) and |
| 21 |
implement such a cache. It's not hard. |
| 22 |
|
| 23 |
Either way, if you want this, the part that will take time is |
| 24 |
integrating it into emerge itself for searching; now if you want to |
| 25 |
write that code twice, go nuts, but someone lazier would do both at |
| 26 |
the same time to make sure they structured the API so it could |
| 27 |
support in one pass, rather than deploying an API, than having to |
| 28 |
shoehorn the cpv argument in. |
| 29 |
|
| 30 |
If people want it, cut a patch and post it for feedback either way- |
| 31 |
bearing in mind that from where I'm sitting, deploying it half-assed |
| 32 |
requiring people to maintain a bunch of text files isn't a viable |
| 33 |
option ;) |
| 34 |
|
| 35 |
~brian |
Archives