Matthias Urlichs wrote: > > As packages are normally upgraded through the life of a system I train > > people to always say 'Y' to the replace a conffile question. Sure > > this may leave the system in a generic and locally unworkable state. > > So why not "N"? That may leave the package, at worst, in a "I can't find > a necessary setting and am going to crash" state, but the following call > to your sysconf program will wake it up right away. Most of the time that would be completely true. Especially for tiny files like /etc/auto.master. But for other files with more documentation in them I prefer to get the new file with the new comments in them. Thinking of files for apache, postfix, bind, and other packages with complex conffiles. But you are right that if my script is written well it would work either way. If my script is not well enough written then I might have a bug. :-) > On the other hand, "Y" will replace that file with a generic version. At > best the package does nothing, but at worst it'll have inconsistent > configuration and do some random things which aren't expected. The package should not do anything unexpected. It should work as if you had just installed the package on a new machine and had not yet done any configuration to it. Debian packages should "just work" out of the box. If a package needs some configuration then it should behave reasonably until further configured. Since my system configuration scripts will be launched and run after the update things will be configured again in just a moment. Mail is the only package which I think has any time where it won't work right on my site with the default configuration. But it should be back working again right away after our scripts run. Other things may be confused for a while but for the time we are talking about it is not significant. Basically I can't give good arguments strongly for either Y or N once we have a script in place to automatically set the package configuration for our site. You have asked a good question and I could see people debating it either way. I just prefer to have the latest commentary in the files. That way new machines and old machines both look very similar. Then by looking at the conffiles you won't be able to tell that it was a potato machine updated to woody updated to sarge. It will just look like a sarge machine. When I write a script to configure a package I normally have two choices. 1) I can replace the entire file with my own configured copy of the file. 2) I can read-modify-write the file to only change what I need to change. This preserves other changes that may have been made in the file. For the /etc/auto.master case I just replace the file whole. For the case of /etc/postfix/main.cf I only modify things like the transport map, which we use on our site, and leave other things alone since there are many options that could be host locally configured there. Getting back on topic for d-m let me suggest that package authors try to set up files such that they can be mechanically updated whenever possible without the need to read-modify-write. Directories of configuration files are great because then a single file can be copied into place and everything else left untouched around it. And this can be undone with a simple removal of that file. Of course /etc/cron.d/* is a classic example of directories of files. And /etc/apt/apt.conf.d/* is another. I can place a file with our web proxy configuration there easily. And /etc/spamassassin/*.cf also allows easy, automated configuration. But ssh is the opposite case. It has only a single file /etc/ssh/sshd_config and so that is a read-modify-write case. Most of these issues are forced upon the maintainer by the upstream architecture. But sometimes you can make it work. The latest bind9 I see uses 'include /etc/bind/named.conf.local' which simplifies the local configuration section. The main file I can leave unchanged and just completely replace the local section. This is a nice way to organize the files. Bob
Attachment:
pgpAmjjjqMUC8.pgp
Description: PGP signature