Re: RFC: Keywords instead of Section
> > OK, so the browser write a list of words with their meaning
> > (optionnally) and asks users to select some of them (or even
> > anti-select). Is is correct ?
> > How many words do you need ?
>
> I guess, the more keywords, the better it gets. Its really something
> like trove (http://www.tuxedo.org/~esr/trove/) or its implementation
> at sourceforge.
Trove seems to follow the same concept at first sight.
It does have a much more complex design, though.
With Metadata, Distribution of Metadata etc. - all that stuff dpkg
and apt already do ;)
Trove seems to be dead, the concept html file is dated 1998...
> I could even think of a unlimited list of keywords, though that would
> throw some problems at us (duplicates, rarely used keywords etc).
Furthermore these Keywords won't have Translations or Descriptions.
That's why i want that Commitee.
> Browsing could be really generic (something like most often used
> keywords on top level) or you browse by categories (ok, categories
> should be keywords, but we would have some keywords which every
> package belongs to, like 'programming language').
As keywords are to be given an explanation, they can also be grouped
(like in tasksel).
I would try ordering the keywords (or groups) by number of matching
packages, this might help filtering out unwanted packages
(say, the top keywords are "x11 / console / daemon / library / docs
/ development files" - this should be really useful, shouldn't it?
What would be the correct way of proposing this for Debian?
This will have to be added to the Debian Guidlines, which are frozen for
woody, aren't they? So this will probably be delayed until the next
release? :-(
Actually it shouldn't do harm to start adding Keywords to the packages,
should it?
Greetings,
Erich
Reply to: