1 |
On Sat, Jun 25, 2011 at 08:22, Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> I think something else that may be important to consider if one is |
3 |
> eliminating category directories is how we'll replace the utility |
4 |
> currently provided by category/metadata.xml |
5 |
> |
6 |
> Some things are simply grossly impractical to maintain individual |
7 |
> metadata.xml for reliably due to volume ( ie: dev-perl/* , last I |
8 |
> looked, the metadata.xml in there presently is largely copy-pasted |
9 |
> between dists ) |
10 |
> |
11 |
Looking at the category/metadata.xml, it's a multilingual dictionary |
12 |
entry and little else. So make a dictionary of tags (categories). |
13 |
And what does the latter half have to do with tagging things? Where's |
14 |
the maintenance? There's the overhead of tagging it once, I'll grant. |
15 |
And then? Tags are unlikely to change all that frequently once |
16 |
they've been added (they don't need to). |
17 |
|
18 |
> Perhaps we need a new way to apply metadata to a whole host of packages? |
19 |
> |
20 |
> Trying to make useflags apply to all packages |
21 |
> with a given tagset would be comparatively messy. |
22 |
> |
23 |
Why do you think that? The directory-like notation doesn't even need |
24 |
to be discarded: |
25 |
perl_module/* ssl |
26 |
|
27 |
> categories also make it easy to do Naïve iteration of packages |
28 |
> efficiently, ie: for the most part, if you want to iterate all |
29 |
> perl-modules, you just need to iterate dev-perl and perl-core , and |
30 |
> that is all, you're not bogged down by stepping into all the other |
31 |
> categories, loading all their files and working out whether or not |
32 |
> they're perl related. ( Yes, I am aware this has its own caveats, but |
33 |
> if you know of these caveats and they're acceptable to your task, then |
34 |
> its fine ) |
35 |
> |
36 |
Or just iterate over the perl_module tag. |
37 |
|
38 |
> the 'virtuals' category also is a bundle of fun. I really do not want |
39 |
> to see virtuals identified only by whatever their unique-idenitifier |
40 |
> might be and the tag 'virtual'. Yuck. |
41 |
> |
42 |
In the first place, it's still no different: mysql (the virtual) pulls |
43 |
in db-mysql (or "charles" or whatever name sounds good) whatever else |
44 |
is available. Or, as I mentioned before, while unique identifiers are |
45 |
really terribly simple, we are fully capable of working around the |
46 |
lack of that feature. What prevents virtual/mysql from pulling in |
47 |
database/mysql? |
48 |
|
49 |
Regards, |
50 |
Wyatt |