Re: Misclassification of packages; "libs" and "doc" sections
On Thu, Oct 12, 2000 at 02:47:44PM -0400, Thomas Hood <thood@excite.com> was heard to say:
> 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.
Yeah. The solution of building an external hierarchy of sections/categories
seems like it would work fairly well; we could make "music" a subsection
of "sound", for instance, and put xmms and denemo in both. I think probably
the categories themselves should be separated from the packages, both so
that it's easier to resolve problems with packages that refer to sections not
in the standard set and so that alternate hierarchical views can be created
easily.. (I can even see shipping several hierarchies with the system)
(note, btw, that some categories may be created which no package is placed
in; for instance, "communication" seems overly broad)
(also, it seems to me that if a package could appear either at a point in
the realized tree or in any sub-node of that tree, it should only appear
in the subnode. That is probably an implementation detail, though, and
I think I know how to handle it. Really!)
You probably won't always want every category to make a difference in your
final hierarchy, so we'll need a way to "hide" some hierarchies. I think that's
easy to implement just by throwing away references to unknown sections; the
only real concern is that packages might get hidden (which could be a feature..)
but that's probably a problem for the interface.
One note: I've totally changed my position on this point :) and would rather
throw away most of the extra tags like Currency and User-interface and simply
use keywords. (note, btw, that UI isn't mutually exclusive) If special
tools need some of these attributes (eg: main/contrib/non-free) they could
remain separate but be parsed as additional categories.
There are a few things that I'm not sure can be done with this system, so
I'm not totally sold on it, but it looks like it might be easier to tweak
this than to do anything else. (eg: I don't see offhand how to get both
programming/editors and editors/programming, both containing the same items)
(Perhaps we could separate a category's name in the interface from its name
in the definitions/package information? So there would be two "programming"s,
one being a real category and the other being a fake subset of "editors". Ewww.
No. Yucky. Maybe allow cycles, but flag already-visited nodes when converting
to a tree? Also yucky.. :( )
Daniel
--
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
| Imagine if every Thursday your shoes exploded if you |
| tied them the usual way. This happens to us all the |
| time with computers, and nobody thinks of complaining. |
\------- Listener-supported public radio -- NPR -- http://www.npr.org --------/
Reply to: