Hello, On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: > Here's a completely different way of doing tags:
As far as sets are concerned, how about PROPERTIES=set? https://bugs.gentoo.org/show_bug.cgi?id=272488 It's been proposed years ago. Is there a need to reinvent sets format every time it's bought up? > 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. I see major disadvantage with this approach. It's painful to maintain. Imagine hundreds of different tags, with each package having at least two tags. You certainly don't expect anyone to be able to maintain that. Also those files cannot be generated since there needs to be some original source of tags information to generate such 'sets' from. I don't need to remind one needs to keep those files synchronized with tree changes (package renames, removals) while tags in metadata.xml automatically ravel with package. Tag is a property or attribute of package and should be implemented as additional package information, metadata.xml is the most natural choice. > Third, make tools that allow browsing, searching etc able to list > things by tag (or sets in general). > > Advantages: dead easy to implement, backwards compatible, we need sets > anyway. PROPERTIES=set have the same advantages - they can also be pulled within dependency tree by other packages. > Disadvantages: doesn't use some horribly convoluted system of XML, > wikis and web 2.0. Using already proven technologies and tools is barely disadvantage. I think last thing we need is yet another obscure format nothing widely usable understands. Sets concept is completely orthogonal to tags concept, please do not mix unrelated things. -- regards MM
signature.asc
Description: This is a digitally signed message part.
