Re: RFC: OpenRC as Init System for Debian
On Mon, 30 Apr 2012 14:44:42 +0300, Uoti Urpala
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
> > to work around the inferior configuration files handling of
> I'm not convinced that the traditional Debian way of directly
> package-created files under /etc would be preferable. I think the
> etc-overrides-lib alternative is technically superior in many
> original version is kept in a known location, it's trivial to
> (temporarily) revert to defaults when you suspect a problem is
> local configuration, it's easier to see what has been locally
> and what hasn't, and especially if the program supports file
> (to include then override the default version) you can resolve
> 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
> to update your local configuration. But this ability isn't really
> inherent to the directly-editing case, nor only implementable with
Currently dpkg allows not only warnings about "some of the cases".
always warns user when config file was changed in package and user
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
manually. So you just can't miss time when config should be edited
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
The only workaround would be to make dummy changes to the
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.
I don't think it would be a very good idea for a low-level package
manager to screen
for any subtle application changes be in the non-default configuration,
its handling, or otherwise a more general
changes in the application functionality itself. To communicate such
subtle application changes to the users,
there are Changelogs, NEWS files, and upper-level tools like
apt-listchanges. Bonus: BTS + apt-listbugs.
I seriously doubt there is more room left for extra engineering.