On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote:
> On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote:
> > Here's a completely different way of doing tags:
> > First, standardise sets. We probably want to go with a format along the
> > lines of:
> > eapi = 4
> > description = Monkeys
> > dev-monkey/howler
> > dev-monkey/spider
> > >=dev-monkey/spanky-2.0
> > dev-monkey/squirrel
> > where eapi has to be on the first line.
> > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
> > monkeys-tag etc.
> This is a bit inverted- tagging is fundamentally pkg specific. If we
> did as you proposed and I wanted to find out all tags/descriptions for
> a pkg, the PM would have to scan every tags file there.
> Additionally, as others have indicated, it sucks have this data tucked
> away in another chunk of the tree, away from where the package data
> actually is (in cat/pkg/*).
> > Advantages: dead easy to implement, backwards compatible, we need sets
> > anyway.
> > Disadvantages: doesn't use some horribly convoluted system of XML,
> > wikis and web 2.0.
> Counter proposal; use what you're proposing as a cache. metadata.xml
> is the proper place for this- we store use.local data there for
> example, and cache the results of it in profiles/use.local.desc. Via
> this vcs concerns are addressed, data locality is preserved, and
> multiple modes of lookup are sanely supported.
> Roughly, and this is definitely a rough sketch:
> <atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom>
> <atom val=">=dev-util/diffball-1.0">awesomeness</atom>
> From there, jammed into profiles, a master description list in 'tag:
> description' style format. Identifying the eapi is easy enough- just
> inspect the atom's that wind up in the tags list. Easy enough.
> Either way... thing everyone admits the current tree format has it's
> flaws; strikes me it's better to fit to the standards/conventions of
> the repo format as it is now.
> <proceed w/ xml bashing>
Of course, nobody said metadata.xml would be the place that's to be
immediately accessed by search tools. But as a data definition is concerned,
metadata.xml is the right place for tags, not some obscure 'package.mask'-
style flat file.
Whether this information is to be processed for easier usage - by generating
flat file with "cat/pkg tag1 tag2 ..." in each line for instance - is
different story and nice to have probably.
profiles/package.mask is quite convenient being flat file (although
package.mask.d seems nicer, different story) as masking/unmasking groups of
packages (KDE releases come to my mind) is a common use case.
Sure, it would benefit from auto-updating (pkgmove mostly as package.mask
editing is otherwise closely tied to package removals anyway).