Gentoo Archives: gentoo-dev

From: Maciej Mrozowski <reavertm@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Are tags just sets?
Date: Tue, 28 Jun 2011 19:11:33
Message-Id: 201106282052.39321.reavertm@gmail.com
In Reply to: Re: [gentoo-dev] Are tags just sets? by Brian Harring
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: > > <tags> > <atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom> > <atom val=">=dev-util/diffball-1.0">awesomeness</atom> > </tags> > > 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> > ~harring
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. @Ciaran 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). -- regards MM

Attachments

File name MIME type
signature.asc application/pgp-signature