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:
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
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
\ / \
\ / \
Interpreter Functional_PL Imperative_PL
/ \ /
/ \ /
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