[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Are tags just sets?
From:       Maciej Mrozowski <reavertm () gmail ! com>
Date:       2011-06-28 18:52:39
Message-ID: 201106282052.39321.reavertm () gmail ! com
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]