Misclassification of packages; "libs" and "doc" sections
We could indeed specify a set of "section" or "topic" words that
exhibited a hierarchy. Modifying my previous proposal (again):
Type: meta|doc|code
Code-level: not-applicable|kernel|lib|sbin|bin
User-interface: not-applicable|line|terminal|X|GNOME|KDE
Currency: current|legacy
Re: {
os-kernel,
support/cpu,support/audio,support/video,support/disk,support/io, ...
interpreters-and-shells,
security/encryption,security/auditing,
user-interface/X,
admin,
development,
comm/telecom,comm/networking,comm/mail,comm/news,comm/www,
text
TeX
graphics
sound
electronics
ham-radio
mathematics,
science,
business
hobbies/pets,hobbies/genealogy, ... hobbies/games
} (any number of these keywords in any order, the first being the "primary" one)
The problem with embedding hierarchy in the names is that
(1) it allows multiple uses of the final word in the name,
which would be confusing; and (2) the hierarchy seems to me
to work at cross-purposes to the scheme of allowing any
number of different keywords, which is effectively changes
the interpretation of the other keywords in such a way that
their parents might not be appropriate. For example, if a
package is in the "admin" and "news" categories then it's
probably to be used to administer a NEWS server and not
to be used to communicate using NEWS as "comm/news" might
suggest. I say that hierarchy should be left out of the
topic words themselves. This does not prevent an archive
viewer app from displaying the packages in a hierarchy;
e.g. the Debian package search page
http://www.debian.org/distrib/packages
might list "telecom", "networking", "mail" and "www" under
a heading "comm". There is no need to make entrench this
layout in the package's description of itself though.
Someone suggested the TUCOWS hierarchy but a quick looks
reveals that it suffers from the same problems as the
existing Debian hierarchy, and then some.
Thomas Hood
Reply to: