[tahoe-dev] [tahoe-lafs] #1009: -SUMO package doesn't build on XP

[tahoe-lafs]

#1009: -SUMO package doesn't build on XP
-----------------------------+----------------------------------------------
 Reporter:  zooko            |           Owner:  warner   
     Type:  defect           |          Status:  new      
 Priority:  minor            |       Milestone:  undecided
Component:  packaging        |         Version:  1.6.1    
 Keywords:  windows openssl  |   Launchpad_bug:           
-----------------------------+----------------------------------------------
 According to Noda, KAI's message of Jan 31: http://allmydata.org/pipermail
 /tahoe-dev/2010-January/003729.html
 {{{
 allmydata-tahoe-1.5.0-r4207-SUMO.tar.bz2 doesn't build on WinXP.
 As in the log below, ssleay32.a is required but there's no such file.
 A tarball without -SUMO happily builds, so there will be a difference
 between pyOpenSSL within -SUMO package and one which is DLed during
 building of non-SUMO package.
 The same problem is observed with allmydata-tahoe-1.5.0-SUMO.tar.bz2.

 > C:\allmydata-tahoe-1.5.0-r4207-SUMO>python.exe setup.py build
 [snip]
 > Searching for pyOpenSSL
 > Best match: pyOpenSSL 0.9
 > Processing pyopenssl-0.9.tar.gz
 > Running pyOpenSSL-0.9\setup.py -q bdist_egg --dist-dir
 c:\docume~1\nodakai\locals~1\temp\easy_install-ck1hd4\pyOpenSSL-0.9\egg-
 dist-tmp-94xmz9
 > error: Setup script exited with Cannot find ssleay32.a, aborting
 }}}
 The reason the non-SUMO build works is that setuptools detects the right
 binary pyOpenSSL package for the version of Python and Windows and
 downloads that. I don't immediately see how to make the SUMO build do the
 right thing, so I guess the solution is to document the SUMO build as
 requiring a pre-installed copy of OpenSSL and a compiler and include paths
 to build on Windows, or perhaps to document the SUMO build as requiring
 that you install pyOpenSSL yourself, or perhaps documenting the SUMO build
 as not supported on Windows.

 Personally, I would rather kill the entire idea of a SUMO build. It is a
 support burden (it complicates the "how to install" process by offering
 another option, and the SUMO option may or may not work) and I personally
 don't value the feature of installing on a Desert Island enough to
 allocate my limited time to it. It certainly doesn't have tests that get
 automatically executed on Windows, or we wouldn't have used Noda, KAI as a
 human buildslave to discover that this problem existed.

 I think part of what is going on is that our packaging needs are changing
 as Tahoe-LAFS is being integrated into distributions like Ubuntu, Debian,
 Fedora, NixOS, and Gentoo. If you are planning to be stranded on a Desert
 Island and you want Tahoe-LAFS there, just install one of those operating
 systems on your laptop before your trip.

 I'm assigning this to Brian since the SUMO build was his idea. Brian:
 please reply with either "fine, kill the SUMO build" or "no, don't".
 Thanks!

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/1009>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid