1 |
On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: |
2 |
> Here's a completely different way of doing tags: |
3 |
> |
4 |
> First, standardise sets. We probably want to go with a format along the |
5 |
> lines of: |
6 |
> |
7 |
> eapi = 4 |
8 |
> description = Monkeys |
9 |
> |
10 |
> dev-monkey/howler |
11 |
> dev-monkey/spider |
12 |
> >=dev-monkey/spanky-2.0 |
13 |
> dev-monkey/squirrel |
14 |
> |
15 |
> where eapi has to be on the first line. |
16 |
> |
17 |
> Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, |
18 |
> monkeys-tag etc. |
19 |
|
20 |
This is a bit inverted- tagging is fundamentally pkg specific. If we |
21 |
did as you proposed and I wanted to find out all tags/descriptions for |
22 |
a pkg, the PM would have to scan every tags file there. |
23 |
|
24 |
Additionally, as others have indicated, it sucks have this data tucked |
25 |
away in another chunk of the tree, away from where the package data |
26 |
actually is (in cat/pkg/*). |
27 |
|
28 |
> Advantages: dead easy to implement, backwards compatible, we need sets |
29 |
> anyway. |
30 |
> |
31 |
> Disadvantages: doesn't use some horribly convoluted system of XML, |
32 |
> wikis and web 2.0. |
33 |
|
34 |
Counter proposal; use what you're proposing as a cache. metadata.xml |
35 |
is the proper place for this- we store use.local data there for |
36 |
example, and cache the results of it in profiles/use.local.desc. Via |
37 |
this vcs concerns are addressed, data locality is preserved, and |
38 |
multiple modes of lookup are sanely supported. |
39 |
|
40 |
Roughly, and this is definitely a rough sketch: |
41 |
|
42 |
<tags> |
43 |
<atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom> |
44 |
<atom val=">=dev-util/diffball-1.0">awesomeness</atom> |
45 |
</tags> |
46 |
|
47 |
From there, jammed into profiles, a master description list in 'tag: |
48 |
description' style format. Identifying the eapi is easy enough- just |
49 |
inspect the atom's that wind up in the tags list. Easy enough. |
50 |
|
51 |
Either way... thing everyone admits the current tree format has it's |
52 |
flaws; strikes me it's better to fit to the standards/conventions of |
53 |
the repo format as it is now. |
54 |
|
55 |
<proceed w/ xml bashing> |
56 |
~harring |