Re: RFC: OpenRC as Init System for Debian

[George Danchev <danchev@spnet.net>]

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

Hi,

> 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.