Re: Misclassification of packages; "libs" and "doc" sections

[Thomas Hood <thood@excite.com>]

>  I think the current problem is just that the sections are not well defined,
> e.g.: X11 should be for packages related to X11/gnome/kde infrastructure,
> not for packages that happens to have X as their interface.. look at this...
> 
> Section: x11
> Package: njplot
> Description: [Biology] A tree drawing program
> [...]

I agree.  I submitted a wishlist-level bug report to the 
maintainer of one of the packages in the x11 section suggesting
to him that although his program had an X interface it really
belonged in "sound" since it was a sound app.  And he replied
to me: Where is it written that x11 isn't for packages with
X interfaces?  There needs to be a policy about this.  Why are
pcmcia-source and printtool in the "admin" section?  Etc.

>  The `base' classification is on a different level, something like this:
> 
>         ^
>         |
>         | base
>         |               interpreters, graphics, etc.
>         o ------------------------------------>
> 
> [...]
>  Uhmm.. I have an idea, let's make a proposal:
> 
>  Package: foobar
>  Section: sound, x11
> 
>  The second one is a secondary section, is as if in `x11' you had this:

This is a good idea.  Modifying my earlier proposal:

There are two reasons a package may fall into more than
one class.  The first is that there are different 
ways of classifying: one may classify by function, topic,
file type, code level, importance, age, etc.  The current
"sections" of the Debian archive are a mishmash of classes
defined in these different ways.  Thus a document describing
a sound library might be in "doc", "libs" or "sound".

The second reason a package may fall into more than one
class is that under most classification schemes a package
can fit more than one description.  An editor can also be
a text processor, etc.

The appropriate way to deal with this issue is to classify
each package in all the different ways that are of interest
to users.  Thus instead of "Section:" we might have (e.g.):

Type: meta|doc|code
Code-level: not-applicable|kernel|lib|sbin|bin
User-interface: not-applicable|line|terminal|X|GNOME|KDE
Topics: [os-kernel]
       [,audio-support][,video-support][,disk-support][,hardware-support]
       [,interpreters-and-shells][,other-os-fs][,old-libraries][,encryption]
       [,printing][,X][,emacs]
       [,administration][,development]
       [,telecommunication][,networking][,mail-and-news][,www]
       [,text-processing][,TeX][,sound][,graphics][,electronics][,ham-radio]
       [,mathematics][,science][,business][,hobbies]
       [,games]

I don't think we need to specify "base" versus "non-base"
since we already have the "priority" field, one of whose
possible values is "required".

Thomas Hood