Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, skip@pobox.com wrote:
Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the Joachim> files (and 'rmdir' directories, but not recursively) that it Joachim> created, and that have not been modified in the meantime (after Joachim> the installation).
That's not sufficient. Suppose file C (e.g. /usr/local/etc/mime.types) is in both packages A and B.
Install A - this will create C Install B - this might overwrite C, saving a copy, or it might retain A's copy. Uninstall B - this has to know that C is used by A and not touch it
Correct. However, in practice, B should not touch C, unless the file is shared between them.
This is a key issue for support of namespace packages, at least if we want to avoid using .pth files. (Which is what setuptools-built system packages do for namespace packages currently.)
Of course, one possible solution is for both A and B to depend on a "virtual package" that contains C, such that both A and B can install it if it's not there, and list it in their dependencies. But this is one of the handful of open issues that needs to be resolved with Real Life Package Management people, such as Debian, Fedora, etc.
I've always thought that the right way to handle the dependency DAG is to treat it as a garbage collection problem. Assume that for each package there is a way to derive the following two pieces of information: (a) whether this package was installed explicitly by the user, or implicitly as the result of a dependency, and (b) the set of dependencies for this package. Then, starting with the list of 'explicit' packages as the root set, do a standard mark & sweep; Any package not marked is a candidate for removal. -- Talin