On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote:
> It seems introduced by the patch debian/patches/setup-modules-ssl.diff
> with description "# DP: Modules/Setup.dist: patch to build _hashlib
> and _ssl extensions statically"
Indeed you're right -- out of the box, python still builds _ssl.so as a
separate module. Sorry for the misinformation -- indeed *nothing* has changed
here upstream, it was just a build patch added to debian's python packaging.
[[
BTW, the actual thing causing that special behavior is not that diff, but
rather is in debian/rules:
egrep \
"^#($$(awk '$$2 ~ /^extension$$/ {print $$1}'
debian/PVER-minimal.README.Debian.in | tr '\012' '|')XX)" \
Modules/Setup.dist \
| sed -e 's/^#//' -e 's/-Wl,-Bdynamic//;s/-Wl,-Bstatic//' \
>> $(buildd_shared)/Modules/Setup.local
which causes all the modules listed as "extension" in
PVER-minimal.README.Debian.in to be compiled in to the python interpreter
instead of built as separate ".so" files.
]]
Despite that not having changed recently, it still seems like there's a problem
in upstream python, which perhaps nobody has thought much about: even if you
don't use SSL, many modules indirectly import either _hashlib or _ssl, and thus
your program is linked against openssl.
You can of course prevent that from happening:
sys.modules['_ssl'] = None; sys.modules['_hashlib'] = None
Luckily, basically everything is already written to keep working if 'import
ssl' fails, so that's fine. (assuming you don't want SSL support, of course).
But you're also left with not being able to 'import hashlib'. While python has
fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if
openssl was found at build time. So you can't just select at runtime that you
didn't want to use openssl.
Not being able to import hashlib unfortunately makes urllib2 (and a lot of 3rd
party packages) fail to import.
Possibly distributors like Debian should just cause _hashopenssl to never be
used, and always use the fallback code, for maximal license compatibility?
On Mar 9, 2011, at 8:27 PM, Joao S. O. Bueno wrote:
> Any libraries commonly avaliable with a CPython instalation can be
> considered as "system libraries" for GPL purposes - and so
> this would fall in the "system library exception" as described by the FAQ:
The "system library" exception is often held not to apply when you are
distributing your program as part of the same system as said system library.
The "system library" exception would also not be applicable if it is the
license of a system library itself that you're violating, e.g. if I have a
BSD-licensed program which starts with "import hashlib, readline".
See also:
http://curl.haxx.se/legal/distro-dilemma.html
James
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
