On 28/08/2018 05:21, Russ Allbery wrote:
Guillem Jover <guil...@debian.org> writes:
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
[…]
* configuration fragment directory → /etc/foo/foo.d/* → do not remove
[…]
This makes sense to me, and your first case would apply if the package has
a specific number of configuration files that can be shadowed in /etc.
I wonder if stateless programms aren't, in a certain sense, using `/etc`
as a conf fragment directory. Take, for instance, a systemd directory
like `/etc/systemd/system/`. It is no conventional ".d" directory, but
it works exactly like that.
After a bit of reflection, I came to the conclusion that purging is a
sort of relic of a bygone era where sysadmins configured applications by
_changing_ files instead of _adding_ files.
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.
Regards,
--
Gioele Barabucci <gio...@svario.it>
