Re: [gentoo-dev] Are tags just sets?

[Kent Fredric <kentfredric@gmail.com>]

On 28 June 2011 15:26, Brian Harring <ferringb@gmail.com> wrote:
> 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
>
>

I agree whole heartedly, I do, really.  Ultimately the best design
will involve:

A. Storing tag data in metadata.xml   ( package -> tag association )
B. Developing a tool that aggregates the contents of metadata.xml to
produce a cache for the data going the other way ( tag -> package )

People searching for packages that match a tag will thusly be able to
read this cached data ( Our primary use case )  and people who want to
know what tags a specific package have will read/augment metadata.xml

I Believe both these parts are required for the design to be successful.

However, both parts have a bit of bike-shedding involved in them,
part A of the system requires changes to exisiting structures, and
part A requires bike shedding about part B's format.

For the sake of simplicity, I'm ( and I believe others ) are simply
suggesting we develop part B first.

Yes, the initial complications in creating the tag indexes will be
somewhat large, but it does mean we can create an early proof of
concept that implements a somewhat "usable" tag-search for users
without having to really touch portage itself.

Once we get that part sorted out and agree upon the general format and
requirements of this index/cache, we can then decide how we'll fit it
in to metadata.xml




-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz