On Tue, 3 Feb 2004, Donovan Baarda wrote:

> I just tested it, and found there was another problem with a set PYTHON
> path. By adding the following to the top of the postinst, I got
> "zope-testcase.postinst configure" to run properly with my development
> environment in place;
>
> unset PYTHONPATH
> unset SOFTWARE_HOME
> unset INSTANCE_HOME
> unset http_proxy
I'll do an upload in the next couple of hours with this changes.

> I have a feeling PYTHONPATH should be unset in all python postinst and
> maybe prerm scripts (something to add to the python policy?). A manually
> set PYTHONPATH can do evil things to any python package's postinst and
> prerm.
God idea to cc debian-python with this problem!

> In my case I had PYTHON path set to /usr/local/lib/python2.3/site
> packages (I override and replace some python packages in my development
> environment), so the postinst was pulling in some python2.3 packages
> even though it was explicitly running python2.2. It's a wonder many
> other python packages didn't bust on installation...
>
> Unsetting of SOFTWARE_HOME and INSTANCE_HOME should probably also be
> standard policy for all Zope packages for the same reason.
Perhaps this is a good idea but I guess it is only necessary if
you are calling some Zope components in the postinst as the zope-testcase
package is performing it.

> Unsetting of http_proxy is only there to bypass a bug in urllib that
> impacts on ZopeTestCase (honours http_proxy, but ignores no_proxy).
IMHO you should reassign bug #230706 to the package which provides Python
urllib to get this problem really fixed.  I can perfectly include the
hack to the postinst script of zope-testcase but simply fixing this bug
would hide the problem of urllib.  Would you like to do this reassigning
(and increasing severity)?

Kind regards and thanks for your testing

     Andreas.


Reply via email to