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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336681268.2227.112.camel@glyph.nonexistent.invalid
