Don Armstrong wrote: > On Thu, 10 May 2012, Ben Hutchings wrote: > > In the etc-overrides-lib model, program defaults and local > > configuration are effectively being merged every time the program > > starts.
This seems to assume that the program would always read both. systemd unit files don't work this way; rather, if the file exists in /etc, then only that version is read. However, you can use ".include" in the file to read the default version and then override only parts. So you can choose which semantics you want for each file you modify. > This is only the case if the configuration files are fine grained > enough that overrides to a configuration file wouldn't also need to > incorporate upstream/packaging changes. In such a case, > etc-overrides-non-etc makes perfect sense, and you wouldn't normally > distribute a configuration file at all (or if you did, it'd just > contain commented, current default values for commonly altered > values). I don't see why you'd equate it being reasonable to override just a few values and there being no need for a distro configuration file at all. Why would it be rare for a program to need distro configuration but have some things the user would want to override independently? > In cases where the configuration files are not (or co-mingled with > application logic), then etc-overrides-lib is the same as running dpkg > with --force-conf-old and having the configuration files in /etc. That's assuming you don't improve the tools; etc-overrides-lib does not intrinsically imply that. And of course you'd still have the other advantages which would not be "the same". -- 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/1336689772.2227.158.camel@glyph.nonexistent.invalid
