Jim Stapleton wrote:
It's a good suggestion but I can see that being more trouble than it's
worth. I wouldn't want to spend countless hours making sure that all
those files, their dependencies, libraries and all that other jazz is in
a jail on its own working smoothly, and even if I get it right upgrading
components (e.g. security vulnerabilities) will prove to be a nightmare.
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.
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?
I would suggest framing either some of the programs/libraries with a
few counts of 1st degree murder, and sending it to jail for life,
where it can run for life in a nice little cell with it's own pet
Would that work? It's probably a bit more work than a desirable
solution, but if you don't need them running in the same "space", it
should work. Or have I completely missed the point (very likely given
Getting a second box is out of the question, for now at least, and while
I thought virtualization might be the answer I see that FreeBSD only has
guest support for Xen :-(
Oh well, guess I'll post to freebsd-python to get some solution perhaps.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"