On Fri, Mar 21, 2008 at 03:02:25PM -0400, 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.
Debian (dpkg) does not allow a file to exist in more then one package (distribution in distutils speak) as I said earlier. Directories can however, they will only be removed if they are empty (i.e. when the last package having that directory is uninstalled). I'm not familiar with namespace packages as I've never used one, but I assume it is just an empty directory with one (empty?) __init__.py file in it? The only way I can see Debian handling that is by having a Debian package providing exactly that __init__.py and all other Debian packages needing that namespace package will depend on it. However, this is shouldn't worry anyone other then Debian I think. If a distribution needs to depend on somthing it will depend on whoever provides the module *inside* the namespace package, not on the namespace itself. So the fact that no distribution provides the namespace.__init__.py file shouldn't have to worry other users of the python installdb. Since easy_install and others shouldn't be messing with debian packages in /usr/lib (they should be using /usr/local/lib or ~/.local [1]) this won't be a problem. For them to interoperate in their own module search paths they might need a virtual distribution though (which Debian could use as well then). Regards Floris PS: Thanks to Ben Finney for bringing the discussions here to the attention of debian-python@lists.debian.org. [1] I am aware of problems with this as explained in this thread: http://lists.debian.org/debian-python/2008/03/msg00021.html For the ~/.local, see PEP 370 mentioned here before. Basically the location of locally installed python modules might need to be revised. Could PEP 370 be extended to cover search paths for modules installed by local administrators? For the PEP262-style database this would probably indeed mean the need for a virtual package (err, distribution) in that database.
Neither overwriting, refusing to install, nor backups will properly address this issue. However, this is properly a topic for the Distutils-SIG or whatever SIG the actual spec goes to. On Python-Dev I'm only looking for a go/no-go on the overall approach.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org