Gioele Barabucci writes ("Bug#907313: Lack of guidelines on purging conffiles
in stateless packages"):
> Most of the current base programs still work in this way, but I suppose
> that it is only a matter of time before everything will switch to the
> stateless paradigm (that is in need of a better name). It is just too
> convenient. At that point the state "configured" would have little
> sense, same thing for the "apt --purge remove" command.
I think we are lookng at this slightly from the wrong perspective.
Why might a user (sysadmin) purge a package ?
I can think of the following reasons:
(i) The package was removed but some of its leftover config content
(eg hook files provided in other packages' .d directories - init
scripts are an example) have bugs which are now causing lossage.
(ii) The user intents to reinstall it but wants a completely fresh,
vanilla, default install.
(iii) The package, even when removed, uses an inconvenient amount of
disk space.
(iv) The package's content in /etc is clutter (getting in the way of
listings, tab completion, etckeeper diffs, etc. etc.)
The idea that config supplied by the user by creating files should be
kept, but the config supplied by the user by editing files should be
removed, doesn't seem to fit into the above.
I think it only makes sense in a world where the latter don't exist.
Debian is not such a world, even though some packages are.
(Of course a package foobar must not delete its /etc/foobar.d
directory completely, even on purge, because another package may have
put a dropping into it.)
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
