-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phillip J. Eby wrote: > 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.
If all Python distributions which install PythonPacakges under the "namespace" package are bundeled as DistroPackages, then the content of __init__.py won't really matter, will it? There won't be more than one copy of the "used-to-be namespace pacakge in this scenario. If it *does* matter (e.g., the DistroPackages need to support use of non-DistroPackage PythonPackages which use the same namespace), then all those DistroPackages will need to depend on a nearly-empty, generated-by-the-packager DistroPacakge which supplies only that file, as Florian says next. >> 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. Right: RPM isn't happy about having a file owned by multiple packages either. >> 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. I think that will need to be an "artifact" DistroPackage (one which has no corresponding Python source distribution). >> 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. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5Fyv+gerLs4ltQ4RAsleAKCyF4qz0lULO1J6vAQMNZyaC+MWfQCbBzfD /eoWYRwwLws24601BAMhdk0= =dNgJ -----END PGP SIGNATURE----- _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
