On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote: > Marco d'Itri wrote: > > I am on friendly terms with many Red Hat people, but it is a fact that > > they take design decisions which are aligned with the needs of RHEL > > and these needs are often far from what is good for other distributions. > > > - configuration files in /etc/ overriding configuration files in /lib/, > > to work around the inferior configuration files handling of RPM > > I'm not convinced that the traditional Debian way of directly editing > package-created files under /etc would be preferable. I think the > etc-overrides-lib alternative is technically superior in many ways: the > original version is kept in a known location, it's trivial to > (temporarily) revert to defaults when you suspect a problem is caused by > local configuration, it's easier to see what has been locally modified > and what hasn't, and especially if the program supports file inclusion > (to include then override the default version) you can resolve more > updates without needing to do 3-way merges by hand. > > The main argument against etc-overrides-lib has been that dpkg can > automatically give warnings about some of the cases where you may need > to update your local configuration. But this ability isn't really > inherent to the directly-editing case, nor only implementable with it. I Currently dpkg allows not only warnings about "some of the cases". It always warns user when config file was changed in package and user edited installed copy. And provides a a nice way to quickly take a look to changes, choose which version to use or even start shell for resolving it manually. So you just can't miss time when config should be edited at all. With "etc-overrides-lib" it's not possible at all... -- WBR, Dmitry
Attachment:
signature.asc
Description: Digital signature