Brian White wrote: > > Could we discuss potential keywords. I need a starting list for bringing > up the topic in the policy group. > > For starters, how about... > > game X-Windows utility web-browser mail-reader > news-reader library database language compiler > interpreter graphical text-based spreadsheet word-processor > music sound graphics modem fax > network internet daemon documentation system > client server devel-tool humor calendar > admin spell-checker msdos-windows compressor multimedia
IMHO I don't think the following keywords are specific enough nor particularly useful for paring down a selection list: daemon, internet, language, multimedia What keywords I would add would be (in no particular order): dev-library dbg-library ups pcmcia security voice window-manager x11-tool-kit language-de language-en language-es language-fr language-it language-ja language-ko language-pl language-sv language-zh manpages emacs vi perl python tcl-tk mail-transfer-agent (mail-user-agent instead of "mail-reader"?) mail-checker (or maybe "biff") pop imap irc finger ftp dhcp file-manager ip-app (packages that deal with ip: ipip, ipportfw, iproute, etc) print-server print-tool postscript encryption ppp smb ntp proxy news sgml backup web-server X-server Some of the above could be expanded into bigger words. But I would like to see all these keywords included. Instead of sound, I would use: cd-player mixer midi-player sound-player The whole idea is to pick keywords that can be used to cut down the list of packages presented to the user. Certain packages will just be pulled in when needed (auto-installed) and as a result don't need to be listed in the selection screen (i.e. library) I would say that it is reasonable that there should be a keyword to describe any class of packages that consists of 6 packages or more. We have quite a few packages. To pare that list of 1500-2000 packages down to no more than 500 interesting ones will take quite a few keywords. > Some of the above are also section names, virtual packages, etc. I think > they should still be allowed (even recommended) as keywords but also > be included automatically from the other fields in the package header. Bear in mind that Section, Priority, Provides and a couple of the other headers are used for keywords too. i.e. if a package is in the graphics section, it is unecessary to give it an explicit keyword of "graphics" because it has an implicit keyword of "graphics" already. This may have been what you were trying to say. If so, then yes I agree. Although these keywords will be considered, I wouldn't rely on implicit keywords that were specified for the dependancy system. In general I would like keywords to be mostly parallel to the dependancy system. I proposed keywords because the dependancy system didn't provide enough of the keywords we need for the UI. Adding more provides makes the dependancy system bloated, while adding more explicit keywords just allows the user to narrow down the list more in the selection screen. Behan -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- E-mail the word "unsubscribe" to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
