m...@linux.it (Marco d'Itri) writes: > On May 11, Thomas Goirand <z...@debian.org> wrote: > >> > Long story short, I still don't see what the fuss is about. >> The fuss is about we're being told that there will be silent >> overwriting of configuration files without being prompted about >> changes, which potentially, will make it horrible to manage >> upgrades in a decent way without knowing the corner cases. > No, not even that: if you edit files in /lib without being aware of the > consequences then you are an idiot and deserve to suffer for it. > The problem with etc-overrides-lib is that a file must be copied in > full from /lib to /etc to be modified, and then future changes to the > same file in /lib will be ignored (so maybe the package will break > because these changes are required, etc).
And...? If it were somewhere under /usr/share/doc/$package/examples, how would that be different? (Assuming that the *default* would then be wired into the binary) You'd still need to copy the file, and if the defaults change under you, you're screwed. Even worse if you have to dig out the possible options, and their defaults from (possibly stale) documentation. But even if everything is in /etc, you can still easily screw yourself over: conf.d/ can very easily break the exact same way. It's not etc-overrides-lib that is the problem. It's defaults changing without notice that is. With the defaults being broken out into files, making a tool that notifies the user preemptively when a default will change, and stops the upgrade, is possible, and is not even hard. You can't do that when the defaults are either unavailable, or subject to change by the admin. -- |8] -- 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/87r4uqqzwt....@luthien.mhp
