[tahoe-dev] state of debian packages
Brian Warner
warner at lothar.com
Thu Aug 6 17:17:04 PDT 2009
I've spent the last day looking into the state of Tahoe-on-Debian. I've
updated the table at
http://allmydata.org/trac/tahoe/wiki/DownloadDebianPackages with my best
guess at the current situation. I removed the "debian users should build
from source" note at the top, in preference to the updated table of
which debian users can and cannot use "apt-get install".
Basically, hardy/i386 users should be ok, and lenny/sid users should be
able to get by. Everyone else is out of luck.
The main issue is that we only have pycryptopp debs for a few platforms
(hardy/i386, lenny/i386 which should also work for sid). We used to have
pycryptopp debs for every platform that we built tahoe debs, but when
the pycryptopp dependency was upped a few weeks ago, those older debs
ceased to meet the requirement, and new ones have not been built. I
started to look into building those debs myself, but it's not easy:
stdeb is a good tool but still rough, and imposes dependencies of its
own (like debhelper7, which isn't available for anything earlier than
hardy).
So, I guess it might be time to give up on some of these platforms. The
ones that are most important to me are:
* debian/sid, because that's what I run
* latest debian release, i.e. lenny
* latest ubuntu release, i.e. jaunty
* latest ubuntu LTS release, i.e. hardy
Also, I personally run i386 and (to a lesser extent) amd64, nothing
else. Tahoe and foolscap are pure-python and therefore
architecture-independent, but the heavy lifting done in zfec and
pycryptopp are arch-dependent. So to support e.g. nexenta or armel,
we'll need pycryptopp/zfec debs produced on such systems.
This would mean we'd stop creating debs for
etch/edgy/feisty/gutsy/intrepid, since without a pycryptopp deb they'd
be useless.
To fill in the gaps, we need:
* tahoe buildslave for jaunty (both i386 and amd64)
* tahoe buildslave for lenny (both)
* tahoe buildslave for sid (amd64)
The sid buildslave is trickier, since sid is (by definition) a moving
target). It should probably be a developer's personal box which gets
updated on a regular basis. I run the sid/i386 buildslave, but I don't
think it's currently producing debs of any sort.
I'll see what I can do about setting up a jaunty slave.. it might be
easiest to cannibalize our edgy slave.
more later,
-Brian
More information about the tahoe-dev
mailing list