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.
