[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian

On Mon, 30 Apr 2012 14:44:42 +0300, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:


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.

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.

Reply to: