On 25 June 2011 23:55, Maciej Mrozowski <reave...@gmail.com> wrote:
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (it's not that hard, renaming stuff in
> app-xemacs mostly) - categories would serve no purpose as id anymore (though
> may need to be provided as backward compatibility - but with symlinks to
> ebuilds/${PN} inside)I think something else that may be important to consider if one is eliminating category directories is how we'll replace the utility currently provided by category/metadata.xml Some things are simply grossly impractical to maintain individual metadata.xml for reliably due to volume ( ie: dev-perl/* , last I looked, the metadata.xml in there presently is largely copy-pasted between dists ) Perhaps we need a new way to apply metadata to a whole host of packages? Also, categories have extra use for simple convenience of their native groupings, ie: I've been known to set USE flags/KEYWORDS that apply to an entire category. Trying to make useflags apply to all packages with a given tagset would be comparatively messy. categories also make it easy to do Naïve iteration of packages efficiently, ie: for the most part, if you want to iterate all perl-modules, you just need to iterate dev-perl and perl-core , and that is all, you're not bogged down by stepping into all the other categories, loading all their files and working out whether or not they're perl related. ( Yes, I am aware this has its own caveats, but if you know of these caveats and they're acceptable to your task, then its fine ) the 'virtuals' category also is a bundle of fun. I really do not want to see virtuals identified only by whatever their unique-idenitifier might be and the tag 'virtual'. Yuck. -- 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
