Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)

[Wyatt Epp]

On Wed, Jun 22, 2011 at 21:25, Duncan <1i5t5.duncan@×××.net> 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