I'm having so much trouble with this. I'm hosting a trac based project
which is implemented in python and uses an sqlite db backend along with
its python bindings. Now it turns out that pysqlite breaks badly
(compiles and installs fine but chokes on import, see
python itself is compiled *without threading* support.
However, on the same box I run a postgresql development and testing
database and we have some triggers and other functions implemented in
pl/python. Guess what? The compile of postgresql-plpython chokes upon
configure if python is built *with threading* support. Running it seems
to work fine, but there's a reason upstream put this check into
configure because supposedly this is known to break things.
Chicken and egg - one of my ports insists on python with threads
enabled, the other port insists I use python without thread support. My
workaround is to compile python without threading, install(or upgrade)
postgresql-plpython, then recompile python with threading, install(or
upgrade) trac and pray that plpython won't eat my dog when I use it. A
really painful and error prone exercise, especially when an upgrade
comes along (security or otherwise).
I need both of these ports on one box and I'm not sure what to do to
sort out this mess properly. Any ideas? What's up with Python's
threading support on FreeBSD in any case, why is is broken?
To get you an idea of what versions I'm running, the affected postgresql
for the trac dependencies the involved culprits are:
sqlite-3.3.8 # peripheral
I remember with python 2.4 I had the same endless issues over a year ago
so it's not 2.5's fault. Oh, and btw, I'm running 6.2-RELEASE-p9 i386.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"