Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC asInit System for Debian]
Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > I don't see how the following would make this comparison with rpm
> > relevant.
> This is debian-devel, and we're talking about configuration file
> handling in Debian, which makes ucf and dpkg relevant.
Yes, ucf and dpkg are relevant to the discussion. However, that doesn't
mean every remark about them would be.
> > Yes, you do need some tool improvements to be able to alert the user
> > about changes.
> Right. So for every package which does this, you have to check to see
> whether a configuration file in /etc has had it's corresponding
> non-etc configuration file changed, and then offer to merge them
dpkg does not currently offer merge functionality, so if you implement
that you're actually improving over what dpkg can do now. And I believe
supporting this should be a reasonably simple extension to ucf.
> Thus, when you fully implement etc-overrides-non-etc, you have to
> handle configuration files in non-etc *exactly* as if they were in etc
> to start with. [Lets not even start with trying to figure out how you
> would handle deleting a non-etc configuration file when there's a
> difference between a non-existent file and an empty one.]
If the application requires the deletion of a file under /lib to achieve
particular configuration semantics, I think that's clearly a broken
application. I don't see how such brokenness would be any more relevant
with etc-overrides-lib than without.
> So there's basically no advantage to etc-overrides-non-etc unless one
> hasn't bothered to implement proper configuration file handling.
Advantages I mentioned earlier would still be there:
It's easier to see what is local non-default configuration. Original
default file is always available in a known location (and very easy to
revert to, temporarily for testing or permanently). You can use
".include /lib/defaultsfile" then override some value, which in most
cases is more maintainable than the 3-way merging required by