When to update config files...
In preparing the pine debian.postinst script to configure pine with the
default NNTP server I looked at the way this script deals with mailname
to see when to modify pine.conf. I was surprised to find that the
decision is made based on whether mailname equals the system hostname!
This doesn't seem to me to be valid criterion for this decision. Suppose
mailname is equal to system hostname (the code purposefully fails to update
pine.conf) and this is an upgrade where the installer chose the
maintainer's new pine.conf (because it contains some fixes for feature
access). The resulting config file ends up having no default mailname. If
I follow this tact with the NNTP server, potentially the same results can
be expected.
I am deeply troubled by the "don't ask, don't tell" policy with respect
to communicating proposed actions to the installation operator and giving
them the options of accepting or rejecting the proposed activities.
In private communications with Ian J. on this subject, his response went
along the lines of: With some 340 plus packages in the Debian
distribution this would constitute too many messages for the user to deal
with.
I say: As someone who has worked at every level of usership I find that
the end-user/system-administrator/application-developer always benefits
from being; 1. Informed about the particulars of the installation, 2.
Offered the opportunity to accept or reject each particular configuration
item.
Two areas of continuing discussion on debian-user tend to support my
position. Many of the complaints about dselect stem from it's desire to
update every package it can find without telling you it's going to do it,
or allowing you the option to skip that step. Many Slackware users (and
others...I don't mean to pick on Slackware) coming to Debian are confused
by the fact that config files aren't where they are used to seeing them.
Both of these areas can be addressed by having installation software
offer more information and control over these issues.
The fact that all automated configuration management typically results in
a package.conf.old file being generated. New installers aren't made aware
at installation time that a change has been made so they don't know to go
look. The automated configuration may in fact be perfect and correct, but
if those facts aren't communicated to someone they are not yet a benefit.
What would fix this for me? (and hopefully someone else too)
What I would like to see is some kind of a log file. All installation
processes would be encouraged to provide information in this log with
regard to what config files are being installed, where they are being
installed, and what modifications were made to them during installation.
If this log file were highly advertised by the various installation
software then the user would have a first path of entry.
I just noticed that I have rambled on for much to long.
The main thrust of this long-winded bleat is, why isn't it appropriate to
ask the installer for permission to modify pine.conf?
TIA,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software Fax: NONE
Black Creek Critters e-mail: dwarf@polaris.net
------------ If you don't see what you want, just ask --------------
Reply to: