1 |
On 28 June 2011 15:26, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> This is a bit inverted- tagging is fundamentally pkg specific. If we |
3 |
> did as you proposed and I wanted to find out all tags/descriptions for |
4 |
> a pkg, the PM would have to scan every tags file there. |
5 |
> |
6 |
> Additionally, as others have indicated, it sucks have this data tucked |
7 |
> away in another chunk of the tree, away from where the package data |
8 |
> actually is (in cat/pkg/*). |
9 |
> |
10 |
>> Advantages: dead easy to implement, backwards compatible, we need sets |
11 |
>> anyway. |
12 |
>> |
13 |
>> Disadvantages: doesn't use some horribly convoluted system of XML, |
14 |
>> wikis and web 2.0. |
15 |
> |
16 |
> Counter proposal; use what you're proposing as a cache. metadata.xml |
17 |
> is the proper place for this- we store use.local data there for |
18 |
> example, and cache the results of it in profiles/use.local.desc. Via |
19 |
> this vcs concerns are addressed, data locality is preserved, and |
20 |
> multiple modes of lookup are sanely supported. |
21 |
> |
22 |
> Roughly, and this is definitely a rough sketch: |
23 |
> |
24 |
> <tags> |
25 |
> <atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom> |
26 |
> <atom val=">=dev-util/diffball-1.0">awesomeness</atom> |
27 |
> </tags> |
28 |
> |
29 |
> From there, jammed into profiles, a master description list in 'tag: |
30 |
> description' style format. Identifying the eapi is easy enough- just |
31 |
> inspect the atom's that wind up in the tags list. Easy enough. |
32 |
> |
33 |
> Either way... thing everyone admits the current tree format has it's |
34 |
> flaws; strikes me it's better to fit to the standards/conventions of |
35 |
> the repo format as it is now. |
36 |
> |
37 |
> <proceed w/ xml bashing> |
38 |
> ~harring |
39 |
> |
40 |
> |
41 |
|
42 |
I agree whole heartedly, I do, really. Ultimately the best design |
43 |
will involve: |
44 |
|
45 |
A. Storing tag data in metadata.xml ( package -> tag association ) |
46 |
B. Developing a tool that aggregates the contents of metadata.xml to |
47 |
produce a cache for the data going the other way ( tag -> package ) |
48 |
|
49 |
People searching for packages that match a tag will thusly be able to |
50 |
read this cached data ( Our primary use case ) and people who want to |
51 |
know what tags a specific package have will read/augment metadata.xml |
52 |
|
53 |
I Believe both these parts are required for the design to be successful. |
54 |
|
55 |
However, both parts have a bit of bike-shedding involved in them, |
56 |
part A of the system requires changes to exisiting structures, and |
57 |
part A requires bike shedding about part B's format. |
58 |
|
59 |
For the sake of simplicity, I'm ( and I believe others ) are simply |
60 |
suggesting we develop part B first. |
61 |
|
62 |
Yes, the initial complications in creating the tag indexes will be |
63 |
somewhat large, but it does mean we can create an early proof of |
64 |
concept that implements a somewhat "usable" tag-search for users |
65 |
without having to really touch portage itself. |
66 |
|
67 |
Once we get that part sorted out and agree upon the general format and |
68 |
requirements of this index/cache, we can then decide how we'll fit it |
69 |
in to metadata.xml |
70 |
|
71 |
|
72 |
|
73 |
|
74 |
-- |
75 |
Kent |
76 |
|
77 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
78 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
79 |
|
80 |
http://kent-fredric.fox.geek.nz |