On Wed, 26 May 2004 16:34:29 +0200, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > Hence you need a hint+policy system, so packagers can provide hints and > you decide what to do with them. I still dont see the NEED for internal package level hinting. All the internal package level hinting can do is give you a very gross grouping package foo belows to group bar. It can't define flexible nested groupings like comps.xml can...so if group bar can ask for group bar-base to be installed when group bar is asked for. At best you can pretend the groups tag give you some sort of linear grouping tree...but if you have a need to list a package in multiple groups, yer screwed. I certaintly would like to be able to see grouping definitions get to the point where users can browse for packages like I can browse for projects through freshmeat. With a mature comps.xml system I could do something like that easily..I could browse by function or i could browse by desktop environment or intended audience becuase the comps.xml is flexible enough to allow packages to exist in multiple parallel groupings. Personally I think all package level hinting does is get in the way because it doesn't provide enough contextual information to be useful for anything. I can't think of a single thing I can do with correct per package group tag, that I can't do with a correct set of comps.xml files and tools that support browsing by comps.xml defined groupings. -jef
