[tahoe-lafs-trac-stream] [tahoe-lafs] #1575: pycrypto-2.4 packaging problems

[tahoe-lafs]

#1575: pycrypto-2.4 packaging problems
-----------------------+--------------------------
 Reporter:  warner     |          Owner:  somebody
     Type:  defect     |         Status:  new
 Priority:  major      |      Milestone:  soon
Component:  packaging  |        Version:  1.9.0b1
 Keywords:             |  Launchpad Bug:
-----------------------+--------------------------
 [https://www.dlitz.net/software/pycrypto/ PyCrypto]-2.4 was
 [http://pypi.python.org/pypi/pycrypto/2.4 released] about a week ago
 (22-Oct-2011). Unfortunately it
 [https://bugs.launchpad.net/pycrypto/+bug/881130 cannot be installed via
 easy_install], which also means that running Tahoe's {{{python setup.py
 build}}} fails if it ever tries to download+install !PyCrypto-2.4 from
 source. This is a drag.

 (note that pycrypto builds find with {{{python setup.py build}}}, and once
 you've done that, you can build an .egg with the cumbersome {{{python -c
 "import setuptools; execfile('setup.py')" bdist_egg}}}. It's just whatever
 magic build process that {{{easy_install}}} or setuptools's automatic
 dependency builder code uses that are failing to do the necessary extra
 configure step).

 Zooko [https://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006807.html
 identified] a couple of options:

 * host binary eggs of pycrypto-2.4 on tahoe-lafs.org
  * we already do this for pycrypto-2.3, for 8 different platforms (various
 combinations of OS, python version, and CPU)
 * set tahoe's {{{_auto_deps.py}}} dependencies to reject pycrypto-2.4
  * the dependency-specification syntax we use in tahoe's {{{__init__.py}}}
 doesn't handle "{{{!=}}}", even though setuptools does, so it's not as
 simple as {{{pycrypto != 2.4}}}.
  * one option would be to pin {{{pycrypto == 2.3}}}
  * we don't really want to reject 2.4 since it works fine once it's built.
 If we were to reject it, e.g. debian packagers would need to patch out
 that line, as pycrypto-2.4 is already standard in sid

 We're still trying to figure out what to do. I'm leaning slightly towards
 doing the binary-egg thing right now, because 1: we were doing it for the
 previous version, and 2: it won't mess up debian packaging quite as much.
 It does mean that we need help from volunteers with various platforms to
 build those eggs.. we only have access to a limited range.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1575>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage