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