[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#907313: Lack of guidelines on purging conffiles in stateless packages



Package: debian-policy

Hello,

the policy lacks guidelines on how to treat user-provided configuration files during configuration purging in packages for programs that follow the "stateless" paradigm (default in `/usr`, override in `/etc`). Should they be removed? Should they be kept?

For example, apticron (the program) has recently switched to a stateless configuration. The default configuration is shipped in `/usr/lib/apticron/apticron.conf` and the local configuration is written by the sysadmin (if they want) in `/etc/apticron.conf`. At the same time the maintscript of apticron (the package) says


    purge)
        [...]
        if [ -d /etc/apticron ] ; then
            rm -rf /etc/apticron || true
        fi
        [...]

That means that purging the package will remove also all the configuration files provided by the sysadmin. Should this be the normality or should this be avoided?

When there was only one configuration file for both the default and sysadmin's settings this could had been a sensible way to purge the package. With these new stateless packages I'm not so sure that removing user-created configuration files makes sense. They are purely user-provided data and will never conflict with future (re-)installations of the same package.

The policy [1] says nothing explicit on this subject, only

> conffiles and any backup files (~-files, #*# files, %-files, .dpkg-{old,new,tmp}, etc.) are removed.

In a message to debian-policy [2], Russ Allbery provided a precedent:
optional files in `/etc/default` haven't historically been removed. (He is not convinced, however, that this is correct solution.)

Could the policy be more explicit on what maintscripts are supposed to do in packages for stateless programs?

Regards,

[1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#id6
[2] https://lists.debian.org/debian-policy/2018/08/msg00182.html

Regards,

--
Gioele Barabucci <gioele@svario.it>


Reply to: