Max Nikulin wrote: > I decided to post to debian-user rather than to the bug tracker to discuss > it from more general point of view: whether this kind of features should be > considered as controversial and whether Debian maintainers should disable it > in default configuration overriding upstream settings. Disabling features > that are convenient in some scenarios may cause conflicts between upstream > developers and Debian maintainers.
There are many Debian packages which, once installed, require affirmative action from the admin to carry out their function or a large chunk of their function. When these are daemons, the usual answer is to put some variable in /etc/default/$NAME which carries a comment: "Set this to true in order to run $NAME. Don't do this until you have configured it, read the warnings in /usr/share/doc/$NAME/WARNING, and considered whether you want to share your clipboard with the NSA" When these are user-run programs, the usual answer is to require a per-user config file (e.g. ~/.$NAME, or ~/.config/$NAME/conf or whatever) that enables specific behavior. Until the configuration is set, the program doesn't do things. A well-behaved program tells the user that it isn't configured and points to documentation. I also note that the Description for stardict does not mention that it is primarily a client for remote servers. Compare the Description for "dict": Description: dictionary client This package provides a client application to query a dictd server. The client-server protocol is TCP-based; the server may then be local or accessed through the network. . The DICT Development Group maintains several public servers which can be accessed from any machine connected to the Internet. The default configuration is to query one of these servers first. This may be changed in the configuration file /etc/dictd/dict.conf. . That's an informative description. -dsr-
