Re: RFC: OpenRC as Init System for Debian
Dmitry Nezhevenko wrote:
> On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> > Marco d'Itri wrote:
> > > - 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.
Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism to
show warnings in these cases, even if the maintainers are aware of it.
The only workaround would be to make dummy changes to the configuration
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.
> With "etc-overrides-lib" it's not possible at all...
This is not true either. You could develop tools that work in this case.
I think there is no fundamental reason why such tools couldn't work
better than current dpkg behavior with equal effort. An easy starting
point (requiring no per-package work at all) would be to show a warning
if an updated package owns a directory under /etc, and that directory
contains non-package-owned files. With some extra work, still no worse
than what's required for current dpkg handling, you should be able to
include information about changes to the corresponding default files (if
any).
Reply to: