On Sun, 2018-08-26 at 12:17:23 -0700, Russ Allbery wrote: > Gioele Barabucci <gio...@svario.it> writes: > > For instance, apache (the application) is configured by some stub conf > > in `/etc/apache` that loads *.conf files from directories such as > > `/etc/apache2/sites-enabled/`. The real files are usually in > > `/etc/apache2/sites-available/`. > > > The purge process for the apache (the package) removes the configuration > > files it has installed and the symlinks it has created but leaves the > > configuration files written by the sysadmin alone. > > Yeah, this is a very interesting example. If the administrator puts a > bunch of local configuration in /etc/apache2/sites-available and related > directories, those are pretty clearly intended to be configuration files > of Apache, but should we delete everything in those directories on purge? > I can imagine someone being *quite* surprised by that. > > Another thing that makes this less obvious is that this mechanism is > frequently used for cross-package cooperation. In a sense, everything > under /etc/apache2 is a configuration file for Apache, but a bunch of > other packages do install files into that hierarchy (including things that > don't strongly depend on Apache), so running rm -rf in postrm purge isn't > necessarily correct.
I think the distinguishing factor here is whether a pathname is a configuration file or a configuration fragments directory. So, I'd say: * configuration file → /etc/foo/foo.conf → remove on purge, even if the package did not ship a file there, because this is "virtually" owned by the program/package (and I can see in the future these being marked as ghost conffiles in the dpkg metadata manifest, for example). * configuration fragment directory → /etc/foo/foo.d/* → do not remove on purge, unless the package ships or creates these itself. This preserves local admin changes, and changes from 3rd party packages. Thanks, Guillem
