[Debtags-devel] roles
Justin B Rye
jbr@edlug.org.uk
Fri, 10 Jun 2005 19:51:20 +0100
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)