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