Re: [RFD]: Question regarding actions to take on --purge of a package.
>>>>> "Raul" == Raul Miller <moth@debian.org> writes:
Raul> On the other hand, I can certainly understand that rm -rf
Raul> /var/log/apache is both simple and robust.
IMHO, it is the best thing. When I purge a program, I want
to get rid of *everything*.
I do not want to come back in 1 years time and wonder, what is this
file /var/log/apache/xyz? Is it still needed? Is the directory still
required? Will I break anything if I delete it manually? How did it
get there in the first place? Maybe my computer was broken into? Or,
maybe I accidently typed in the wrong cp command many years ago, and
the file went in the wrong spot?
This is why I particular hate the bug in dpkg that warns the
administrator that empty directories have not been deleted. It means
that old directories may lie around for ever which are no longer
used/required. Unless you write down these warnings as they occur, but
even then you have to guess which directories are still required.
The problem I see is all of this ugly mess is forced into each
applications prerm and postrm scripts, when it should be dpkg dealing
with it, in a consistant way.
IMHO: A solution to all problems:
*Any* file that is owned by a package must be declared by that package
to dpkg, this includes any log files, database files or configuration
files that the package might create. So, for instance, dpkg -S
/var/log/apache/access.log would return apache. This doesn't make them
installable files though, just files associated with the package.
When removing the package, dpkg does not warn if directories cannot be
deleted, but continues to associate the directory with the
package. dpkg deletes the files it normally would for the remove
package operation.
When purging the package, dpkg deletes all files it knows about. There
could be an option not to delete files under /var/log, if required[1].
Then, if dpkg still cannot delete the directories[1], it warns (eg by
sending EMAIL) the administrator that certain files and directories
exist, and it has no way of knowing what package (if any) they might
be associated with. This could be a shell script that removes the
files and directories one at a time, so the administrator can check it
for anything important before allowing it to execute.
Notes:
[1] this configuration could be made more general. Also, dpkg could
move the files elsewhere, to indicte that the package has been purged,
and they are no longer required by the system
[2] Ideally, when all applications support the scheme, this should
never happen unless the system administrator manually created the
files.
--
Brian May <bam@debian.org>
Reply to: