Re: Misclassification of packages; "libs" and "doc" sections
Now that it's relevant, I'm putting some stuff from a discussion
at progeny-debian:
* About task packages.
Task packages might not be a very good idea. I understand that somehow
making categorization information into a package seems attractive to
coders, but I'd tend to think that categorization is an issue that
is orthogonal to packaging. Package semantics does not necessarily
subsume issues related to categorization. A clear design would include
* A package manager that deals with packages. (If categories are
packages, then dealing with them as though they're ordinary
packages should be sufficient. Which I don't believe to be the case)
* A category manager that deals with categories.
In other words, categories, IMHO should be separate entities as I'd previously
written on debian-devel. Of course, nobody had taken any notice of it
except a few people.
* On using a directory structure (in response to a question on using...)
I see that you'd like a more general categorization model than
of an is-a tree. I'd suggested in my mails an OO system that allows
(multiply inherited) is-a and part-of hierarchies for package classification
and two possible uses of such package classification. I'd thought that
this would be done in a way external to packages. The developers would work on it
collectively to enhance the precision of classification information.
Then it occured to me that starting off with a complete and possibly complex
model might not be very desirable for a working prototype. Now instead
I think that one should provide the basic framework and tools that let
you work with categories, and solve some of the simpler problems and offer
again a simple categorization scheme. For instance, using a directory
structure *just like* tucow's directory structure would be a very good idea.
Why? Because we can steal tucow's or cnet's or winfiles's, and of all those that
do some sort of software classification. I mean, just plain *steal* their schemes
make it look better suited to Debian, and then put all packages in these buckets.
You may think of stealing redhat's hierarchy too, but I think download sites
have better classification. This list would be a good place to develop
such a classification tree.
Multiple categories and the fancy things about categories can be omitted.
Besides, if one thinks "user" it will be obvious that it will be beneficial
to make it look *just like* those software directories. Assume that you've
adapted some weird ontology scheme due to some obsessed CS student
like me. I guarantee that you'll run into more problems with users if you
already haven't stumbled into some serious implementation problems :)
If we're being pragmatic, perhaps offering a very limited multiple category
feature in addition to a manual hierarchical classification will suffice.
The first category indicates for what the software is intended for.
sound/music/composition/trackers ... just made that up. the hierarchy from tucows
will do. the second category indicates what interface the program has
console, GUI, or automated (daemon, but in parantheses ;). That might be it.
* Implementation (An extremely repelling idea!)
I have an idea that you'll most probably despise. ;) It should be something
that users can understand and modify for their needs. For this there should
be both a category browser and an editor. Implementation-wise, this thing
would better have its own nice interpreted language, or based on something
readable (I generally think - no XML, no Java, no XML, no Java). Can something
be done with existing interpreted languages? Most probably. Who's the local
perl monk here? :)
Thanks for your patience,
--
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: