Re: Making some tags mandatory
On Fri, 27 Feb 2009, Enrico Zini wrote:
The way I see it, the last thread on sections has opened a bit of a can
of worms: now first everyone will want a section for their favourite
topic, then there is going to be a fight on which one to pick in case
packages that could belong to more than one section. Been there, done
If you just open this can of worms which is basically about categorizing
Debian packages I might throw the method which was invented by Debian Pure
Blends effort into it as well. The rationale behind this is that my plan
is to find a closer connection between tasks and debtags. For those who
have no idea about those tasks you might like to have a look for example
at the tasks page of Debian Science.
The reason why I rise this issue here is that the following discussion
quite regularly pops up: Does package x belong to category A or B. This
question is an issue for the section we put some packages into - it is not
for DebTags (if I understand debtags correctly this was one of the main
reasons to invent it) and it is also not true for tasks because package
x can be useful in more than one task and so it can be added to the according
task file. For instance the question whether the package octave is
a package in the field of mathematics or physics or numericalcomputation
just makes no sense. The question is rather: Does a mathematician need
octave? Does a physicis need octave? etc.
So I would like to bring back the issue of categorisation from a
sophisticated scientific discussion about the "right" category for
a package to the user oriented view: I want to solve a certain task -
just install all packages which might be useful for this task and
please do not force me to understand your complex categorisation
scheme (how well thought it might be).
There are just different points of view: From a distributors point
of view it makes sense to put packages into different sections to
give some structure to the archive.
From a users point of view these sections sometimes do not make much
sense and he has to seek for packages in "unexpected" sections. Blends
try to follow the user oriented view and ask users what package they
would like to install to solve a certain task.
So far for the theory. I would like to make you think about other
use cases of user oriented categorisation in the sense above. For
instance I could think about fields like accessibility oriented
packages, packages regarding forensics, etc. Just think about
whether it would be interesting for users who need a quick overview
about the available packages for a certain task (well, in Blends
we stretch the system in the tasks pages even further to packages
which could be included in the future for some tasks).
If the concept works out as promising or successful I plan further
integration with DebTags (for instance including DebTagged packages
if missing on the tasks pages, adapting DebTags to the available