[Debtags-devel] roles

[Enrico Zini]

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 10, 2005 at 07:51:20PM +0100, Justin B Rye wrote:

> 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?=20

It isn't obvious to me yet.  I think it depends mostly on how the facets
and tags are defined, and so far they aren't defined very formally.

That is: if web::server means "this package is a web server", then
apache-doc won't have that tag.  However, if web::server means "it is a
web server or it is related to web servers", then apache-doc definitely
fits.

How we define facets it's also to do on what we'd expect to come out
when we select them.  I'm personally in favour of too large results over
too small ones: I see Debtags as something that is queried by an
iterative process of narrowing the results until one gets a list which
is small enough for their needs.  I expect a tipical debtags search to
go like this:

  16000 packages
    Select one tag among 200 available
  2000 packages
    Select one tag among the 50 available
  100 packages
    Select one tag among the 10 available
  15 packages
    OK, it's not scary anymore, let's see the list

This means that I'm fine if apache-doc shows up when I ask for
"web::server": if it's the server software that I want, I'll then ask
for something like "role::daemon", while if it's documentation that I
want I'll then ask for something like "role::documentation".

At the same time this will allow me to select "role::documentation" to
start with, and then choose "web::server" to get documentation about web
servers, or select "role::daemon" first and then choose "web::server" to
get web server software.


> 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?=20

While I'm happy to get extra results for -doc packages, there are
packages such as shared libraries or unneeded localisation packages that
one could wish to hide.

That is done through the use of the "special::auto-inst-parts" (that
would tag shared libraries and many -data packages) and the "culture"
facet (through a filter such as "!culture::* || culture::(my culture)").


> Given such a mechanism, you can factor out the -dev or -doc packages
> when designing the set of facets.  For instance:
>=20
> 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.=20

That would be a less obvious way of deciding first or second class
packages: a Gnome developer might consider libgtk-dev more primary than
any SDL game, for example.

What I understand you're asking could however be obtained by using some
tags to filter out packages: you could ask the package manager to
automatically hide all "devel::library" packages, and the grumpy Gnome
developer could ask to hide all "games::*" and "suite::kde" packages.

So, yes, the idea of "secondary packages" is good, but I wouldn't obtain
it by some specific categorization, but rather by allowing people to
configure their preferences into the package manager.


> media/format:
> * End-users searching for audio-handling packages will find xmms but
> 	not xmms-doc or xblast-tnt-sounds.

Here I wouldn't mind if people that go for media::audio found
xblast-tnt-sounds (I'm a bit less sure of xmms-doc).

However, the "media" facet wouldn't be the only point of entry for audio
applications.  One could very well start from "sound::player" or
"use::playing", both of which wouldn't lead to xblast-tnt-sounds.
If one starts from "media::audio" and there are too many matches, it'd
be very easy to find use::playing and sound::player among the remaining
tags.

  (I now realise that if instead "media" is renamed in "works-with" or
  "specialty", that would automatically rule out all non-software
  packages such as 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.=20

Here I'm a bit skeptical with categorizations: why do I need to put
"printable" or "web" under "doc" and not somewhere else?  They will
automatically appear among the remaining tags after I chose "role::doc"
anyway, but at the same time "role::doc" will appear after I choose
"web::server", giving me two different points of entry to get to the
same place.  And I do want to have different points of entry, because I
never know what's prioritary in the mind of a user when they start a
search.


> 	(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?)=20

Interesting question.  But we can solve that easily by delegating the
debian policy on that: they already say than when a package has a lot of
documentation or icons, or when they could be useful without the rest of
the software, then it should be split up.


> 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.

I'm replying to this on a different mail, since it spawns a proposal
that would risk being lost at the end of the mail.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@enricozini.org>

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCqwUl9LSwzHl+v6sRArijAJ4+sTc7bEolbzy0H0VUAsdIDtSc8ACgherD
AU9Sgln77g5/bLf8HduBu3s=
=A2FE
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--