At 10:17 PM 3/21/2008 +0000, Floris Bruynooghe wrote:
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).
This is a general problem with system package managers, actually. Few allow a file to be provided by more than one package.
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?
It's not empty; it has to contain a namespace declaration. There's another approach that can work around the absence of the __init__.py, by using .pth files, but it's messy, and I'd like to get rid of it if possible.
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.
Alas, it'll probably affect most package managers.
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.
Well, somebody still has to create the __init__.py, and own it for purposes of uninstallation.
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.
If the new PEP (262 redux) contains anything about actual directory locations on any system of any platform (other than as examples), I'll consider it a failure. Thinking about specific locations while talking about the new PEP should be considered a segmentation fault. :) The only thing that matters for the install db is where things are in relation to an installation target directory. Which reminds me -- the install db should support install-dir-relative paths, and probably should require them for anything that's installed under the library install dir. (Many use cases of this stuff will be *relative*; packaging an application as a giant tarball and unpacking it somewhere else on a system, or copying an application tree from point A to point B, should not render the data therein unusable.)