Denis Dupeyron wrote: > On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov <geo...@gentoo.org> > wrote: >> Besides, in my opinion, the ability to see "what's there" in at least >> minimally categorized way without having to resort to using some special >> tools or going to some website is worht something. In this vain I was >> proposing going the opposite direction - to allow arbitrary nesting of >> categories, like going sci-math -> sci/math and deeper (then packages >> would naturally be specified by "FQEN" - fully qualified ebuild names). >> Its not like tree walker would be the most complex part of code in >> portage.. > > Actually we'd want both tags and nesting. They don't address the same > issue. > > Arbitrary nesting of categories allows better management and storing > of ebuilds. It could also allow a meta-ebuild to depend on a whole > subcategory to ease maintenance of said meta-ebuild. It's more a > developer's feature. > That sounds very similar to sets? Sorry if I'm missing something obvious, but I thought sets were used with kde4; if they are unavailable to the ebuild author, perhaps a suitably-defined extension (for in-tree sets) might be useful? The obvious advantage being that they are not tied to a specific category, ofc; could you expand a bit on 'better management and storing'?
> Tags allow ebuilds to appear as being pertinent to more > (sub-)categories than just the one they're stored into. It may help > some of us locate packages they need in a better and/or faster way. > It's more of a user's feature. > Tags sound cool. I'm opposed to losing the current single flat category schema, fwtw, unless it enables something majorly-useful. It's *way* better than other distros (I am deadset against losing all categorisation) and still nice and immediate.