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