1 |
On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote: |
2 |
> On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: |
3 |
> > Here's a completely different way of doing tags: |
4 |
> > |
5 |
> > First, standardise sets. We probably want to go with a format along the |
6 |
> > |
7 |
> > lines of: |
8 |
> > eapi = 4 |
9 |
> > description = Monkeys |
10 |
> > |
11 |
> > dev-monkey/howler |
12 |
> > dev-monkey/spider |
13 |
> > |
14 |
> > >=dev-monkey/spanky-2.0 |
15 |
> > |
16 |
> > dev-monkey/squirrel |
17 |
> > |
18 |
> > where eapi has to be on the first line. |
19 |
> > |
20 |
> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, |
21 |
> > monkeys-tag etc. |
22 |
> |
23 |
> This is a bit inverted- tagging is fundamentally pkg specific. If we |
24 |
> did as you proposed and I wanted to find out all tags/descriptions for |
25 |
> a pkg, the PM would have to scan every tags file there. |
26 |
> |
27 |
> Additionally, as others have indicated, it sucks have this data tucked |
28 |
> away in another chunk of the tree, away from where the package data |
29 |
> actually is (in cat/pkg/*). |
30 |
> |
31 |
> > Advantages: dead easy to implement, backwards compatible, we need sets |
32 |
> > anyway. |
33 |
> > |
34 |
> > Disadvantages: doesn't use some horribly convoluted system of XML, |
35 |
> > wikis and web 2.0. |
36 |
> |
37 |
> Counter proposal; use what you're proposing as a cache. metadata.xml |
38 |
> is the proper place for this- we store use.local data there for |
39 |
> example, and cache the results of it in profiles/use.local.desc. Via |
40 |
> this vcs concerns are addressed, data locality is preserved, and |
41 |
> multiple modes of lookup are sanely supported. |
42 |
> |
43 |
> Roughly, and this is definitely a rough sketch: |
44 |
> |
45 |
> <tags> |
46 |
> <atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom> |
47 |
> <atom val=">=dev-util/diffball-1.0">awesomeness</atom> |
48 |
> </tags> |
49 |
> |
50 |
> From there, jammed into profiles, a master description list in 'tag: |
51 |
> description' style format. Identifying the eapi is easy enough- just |
52 |
> inspect the atom's that wind up in the tags list. Easy enough. |
53 |
> |
54 |
> Either way... thing everyone admits the current tree format has it's |
55 |
> flaws; strikes me it's better to fit to the standards/conventions of |
56 |
> the repo format as it is now. |
57 |
> |
58 |
> <proceed w/ xml bashing> |
59 |
> ~harring |
60 |
|
61 |
Of course, nobody said metadata.xml would be the place that's to be |
62 |
immediately accessed by search tools. But as a data definition is concerned, |
63 |
metadata.xml is the right place for tags, not some obscure 'package.mask'- |
64 |
style flat file. |
65 |
|
66 |
Whether this information is to be processed for easier usage - by generating |
67 |
flat file with "cat/pkg tag1 tag2 ..." in each line for instance - is |
68 |
different story and nice to have probably. |
69 |
|
70 |
@Ciaran |
71 |
profiles/package.mask is quite convenient being flat file (although |
72 |
package.mask.d seems nicer, different story) as masking/unmasking groups of |
73 |
packages (KDE releases come to my mind) is a common use case. |
74 |
Sure, it would benefit from auto-updating (pkgmove mostly as package.mask |
75 |
editing is otherwise closely tied to package removals anyway). |
76 |
|
77 |
-- |
78 |
regards |
79 |
MM |