Bug#907313: Lack of guidelines on purging conffiles in stateless packages
On Sun, 2018-08-26 at 12:17:23 -0700, Russ Allbery wrote:
> Gioele Barabucci <gioele@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
Reply to: