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

[Thomas Hood <thood@excite.com>]

I think that all we really need is some new fields
in the package description---one field for each
mode of classification that might be of interest
to users.  It would then be up to some keen programmer
to write a package browser that would offer different
views of packages according to their properties so defined.
   "Show me a hierarchy of all packages listed
    first by function, second by user interface."
(Programs with multiple UIs would show up in multiple
locations in this hierarchy.)
   "Now show me all the X apps classified by license."
   "Now list all the GNOME apps."
   etc.

Each of these new fields will be either single-valued or many-valued.
   Type:       single valued  (meta|doc|code)
   Basic:      single valued  (yes|no)
   Functions:  many valued (driving, emulating, editing, etc.)
   UIs:        many valued (console, terminal, X)
   etc.

If the function words chosen are specific enough then with
the aid of the other classification modes it should be fairly
easy for a user to zero in on the packages that interest him.
If he asks for a GNOME editor, that handful of packages will 
be listed.

Question: What happens if we later want to split up a class,
e.g., a UI class such as "X", into subclasses
such as "X-only", "GNOME" and "KDE"?

Answer: Then we add the names of the new subclasses to our
list of legal UI designators, encourage maintainers to
update their packages to contain the more specific designators,
but in the meantime code into our package browser the
knowledge that "X-only", "GNOME" and "KDE" are subclasses
of "X" so that the former will be displayed beneath the
latter in any hierarchical views of the archive and all
of them will turn up when the user asks for "all the UI:X11 apps".

In a similar way new designators could be defined as
conjunctions or disjunctions of existing designators.
All these relations would be known to the package browser,
but not, of course, encoded in the packages themselves.
(The browser would display the conjunctive class A&B as
the B subclass of A and as the A subclass of B.  It would
display the disjunctive class AvB as the immediate
superclass of A and of B.)

The job ahead of us, then, is twofold.

First, to decide which classification modes are of interest.
Second, to come up with a list of values for each mode---a
list of package types, of UIs, of functions, etc.  As has
been suggested before, the way to go about this is to work
up an initial system and then go through all the packages we
have and classify them according to it, adapting the system
as we go until we have something that's nice.  Once this is
done the classification info can be entered into an overrides
file for the information of the package browser; new or modified
packages would be required to include the info in the package
itself so that it could be queried using dpkg.

So, to begin with, what are the ways in which users would
like to see packages classified?  The following have all
been suggested:

   Type:
   Function:
   User-interface:
   Domain:
   Code-level:
   Project:
   Author:
   License:
   Distributor:
   Currency:

Which of these, or which others, should be adopt?

Function and UI are obviously two of the useful ones.
So, what should our (initial) list of functions and user
interfaces be?

Thomas Hood