[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Thomas Hood wrote:
> 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.

The problem is, which modes of classification are useful?
I think we should be conservative about fields in the package
description simply because it's a big change and hard to retire.

I'm in favor of a single new field for packages,

This will have to be handled at separate levels as pointed out,
(override, etc.) so introducing *only one* new field seems to
be the right way.

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


nice, but you see those are all possible in the more general systems
we have been discussing, too.

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

So each classification mode represents a tree hierachy.

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

category expressions in this manner are possible in the
single category hierarchy also. I had the same idea, as well.

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

Well, these all look very intuitive. But we can't know if these
are really top-level categories until we put every package
in the hieararchy. My only objection is an implementation detail,
let's say. Let's not introduce many new fields into package control

Category: Type:Application, Function:Editor&Devel&Lisp_Interpreter,
  , UI:X11, Author:FSF 

would be more reasonable. of course in my proposal this goes something like

Category: Application, Editor, Devel, Lisp_Interpreter, X11, FSF

Since all node names are unique in the hierarchy. Top level categories
don't have to be mentioned. And of course, you can *change* the category
hieararchy above this package. That is you can redefine the ontology
of Lisp_Interpreter..

   Say it used to be


But during the development of the hierarchy we observed that
there are other kinds of interpreters, too. We also noticed
that a Lisp_Interpreter is a functional programming language
(perhaps that's not an is-a relation, but it is indeed a
special form of a functional programming language, in that
it implements one with a communication interface in the
same language)

       Devel                   Programming_Language
          \                        /           \
           \                      /             \
          Interpreter         Functional_PL     Imperative_PL
          /        \            /
         /          \          /
     Calculator     Lisp_Interpreter

The categories here are imaginery, but I wanted to show
what sort of use the system (Daniel and I have been discussing) 
can have. As we did these changes to Lisp_Interpreter category,
we didn't touch the packages which claimed to be Lisp_Interpreter.

Note that a category is *not* eligible unless there are a
sufficient number of packages that are members of that category.
That is, there is no category in Debian called Violent_Penguin_Slaughter_Game
there are just not enough programs that would be in that category.

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

Well, I myself suggested type and ui in the progeny-debian
discussion along with a tree for the two. But I'm saying here
that ours can be better. ;)


Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Reply to: