Re: Keywords (!)
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:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
--
E-mail the word "unsubscribe" to deity-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@debian.org .
Reply to: