[Python-Dev] How we can get rid of eggs for 2.6 and beyond

Talin talin at acm.org
Sat Mar 22 06:20:43 CET 2008


Phillip J. Eby wrote:
> At 11:21 AM 3/21/2008 -0500, skip at 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



More information about the Python-Dev mailing list