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
> together.
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
"traditional" conffiles.
Reply to: