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, [EMAIL PROTECTED] 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.) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
