On Thu, Feb 12, 2009, Les Mikesell wrote:
Bill Campbell wrote:
Of course we don't do things that are likely to take a critical service down without proper prior planning (often found out the hard way on our own systems :-). If an update is likely to have an impact on operations, it is scheduled during a maintenance window.
In other words you'd dedicated sufficient human resources to undo whatever damage the package management system causes...
Isn't that what our customers are paying us to do?
That has to be true now matter how one is doing updates.
Yes, but the extent to which it is actually required depends on how badly the intended automation fails. I think at least in theory, the parts of config files that are likely to need user modifications are supposed to be extracted to /etc/sysconfig/... so the files included in RPM updates generally won't have local changes and can be replaced without regard to the old contents. And programs suitable for inclusion in an 'enterprise' distribution should be designed so as not to require non-backwards-compatible changes in updates.
With OpenPKG all configuration files are under $prefix/etc/packagename where $prefix is the base directory of an OpenPKG instance (there may be more than one on a single system), and packagename is the name of the package, postfix, amavisd, clamav, mysql, etc. One of the basic principles of OpenPKG is to have absolutely minimal footprint on the installed system, only 7 lines in /etc/crontab, and the appropriate /etc/init.d entries (these actually vary depending on the type of host system).
Some packages have multiple configuration files with only those for site parameters being declared at %config files in the RPM SPEC file. The issues occur when one has large, ugly configuration files (can we spell amavisd.conf :-), and there's a major version update with lots of new variables or variable name changes.
FWIW, to bring this back to the djbdns topic, the *ONLY* configuration file in our OpenPKG packaging of djbdns, daemontools, and ucspi-tcp is the dnsroots.global file used by dnscache. Each server installed is in its own directory which is not affected by updates.
Bill