[Debtags-devel] roles

[Justin B Rye]

I think my questions about "duplicate" facets would make more sense
if I was confident what the current policy is about "secondary"
packages like tuxpaint-data or apache-doc or xlibs-dev.  Am I right
to say they're being tagged just like their "primary" packages, plus
extra tags to mark them as doc-packages or whatever? 

This seems to mean that any search for HTTP daemons is going to get
inappropriate hits for -doc packages and the like.  Are there (plans
to implement) mechanisms to keep packages in supporting roles out of
the results unless users are specifically looking for them? 

Given such a mechanism, you can factor out the -dev or -doc packages
when designing the set of facets.  For instance:

interface/uitoolkit:
* GTK developers who have somehow misplaced libgtk-dev can find it
	by searching with "show secondary packages" turned on (or
	maybe this is implicit with searches on role::dev).
* End-users searching for "SDL packages" can do it on a single UI
	facet, without being distracted by commandline -dev
	utilities or totally interfaceless -doc collections. 

media/format:
* End-users searching for audio-handling packages will find xmms but
	not xmms-doc or xblast-tnt-sounds.
* People specifically looking for PDF documentation might be better
	off with something like role::doc::printable versus
	role::doc::web. 

	(Hmm, maybe there still needs to be a "subsidiary contents"
	facet for packages that happen to include their own manuals,
	but where's the borderline?  Do we tag packages that include
	a FAQ.html?  How many .xpm icons does a package need before
	it's a candidate for contents::raster-image?) 

And I definititely feel that all the data:: categories belong in
role::, along with new tags for "dependency metapackage" and "dummy
package for upgrades" and a couple of others.  Though this may of
course be me showing my admin-centric bias.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)