1 |
On Wed, Jun 22, 2011 at 21:25, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> Umm... I believe Ciaran meant "no description" in the practical PM |
3 |
> implementation rules sense, not in the general definition sense, which I |
4 |
> suppose most folks here understand by now. |
5 |
> |
6 |
Most is not all. ;) In general, I try not to assume everyone is on |
7 |
the same page; one of the things academia got right. |
8 |
|
9 |
> Until that happens, or at least is actually in process, it's all talk. |
10 |
> |
11 |
Shall we call it "in process" right now, then? My impression was he |
12 |
was calling for us to get down to brass tacks and hammer this out for |
13 |
real. Apologies in advance for the long post. |
14 |
|
15 |
As far as what I've said already, a quick read of the PMS tells me |
16 |
that "[metadata.xml's] exact format is strictly beyond the scope" of |
17 |
it. Would it be acceptable to add this to the ebuilds themselves? |
18 |
Otherwise, at least the tags become mandatory and drag the xml into |
19 |
this. Given that encoding tags into directory paths is why we're |
20 |
talking about this in the first place, that's out; the third obvious |
21 |
solution is a separate file for each package, but....yeah, not where I |
22 |
would personally go with it without thinking long and hard about the |
23 |
other two first. |
24 |
|
25 |
The directory paths themselves....well, one solution I noted from the |
26 |
other thread was to populate tag directories with symlinks. I've done |
27 |
similar things, but always thought of it as a hack, so I'm reluctant |
28 |
to advocate for building a deployable semantic system on top of it-- I |
29 |
could potentially be convinced otherwise, though. Given that tags and |
30 |
categories have roughly the same purpose and end result, a flat ebuild |
31 |
directory referenced only by its metadata should certainly be |
32 |
possible. If this is going to happen, and happen right, what this all |
33 |
looks like in the filesystem is moot anyway. |
34 |
|
35 |
I bring this up because there are several packages with the same name |
36 |
and different qualification. Obviously, they'll have different tags |
37 |
because they're not the same thing, but neither should they share the |
38 |
same directory. So the simple solution is to just change the package |
39 |
names so we avoid collision and preserve our flat ontology (I've |
40 |
forgotten the objection to doing this; please forgive). The next |
41 |
simplest solution is to just name the directories as hashes in-tree |
42 |
and cover it up with software magic (I'm pretty sure this ends up |
43 |
pretty ugly, implementation-wise). |
44 |
|
45 |
For the sake of migration, packages should probably have their current |
46 |
category/directory added to the tags; deprecate and remove after |
47 |
sufficient time (I think this is one of those two-year changes?). |
48 |
|
49 |
Those are roughly my thoughts for the time being. Let's do this thing! |
50 |
|
51 |
Regards, |
52 |
Wyatt |