wiki:Packaging

Version 15 (modified by zooko, at 2008-04-12T03:10:49Z) (diff)

edit and update

Packaging

We want to package Tahoe for people to download and use and we want to use 3rd-party libraries. The following are our current desiderata:

  • For certain deployment targets (namely, recent Debian and recent or Long-Term Support Ubuntu), we produce a Tahoe binary package for that platform, ship that package to a user using that platform, they can install that package, and it will work. That is: user doesn't have to manually satisfy any dependencies by building other packages.
    • This is accomplished by adding the following clause to /etc/apt/sources.list and then running apt-get install allmydata-tahoe:
deb http://allmydata.org/debian  $DIST  main tahoe

For libraries that Tahoe uses, we have these desiderata:

  • We use the source code as it is written by upstream. That is: no patching required.
  • Use it as it is packaged by upstream. That is: we prefer to get a copy of the source code of the package as upstream prefers to distribute such source code, rather than by pulling from their revision control tool or so on. (But we strongly prefer source packages to binary.)
  • The user doesn't have to manually resolve any conflicts (this means that we either have to automatically use a 3rd-party library if it is already installed or else we have to automatically force Tahoe to use the copy that it came bundled with).
  • Make it convenient for someone to use other versions of the packages that we use e.g. system-wide packages or newer or alternate versions, etc..
  • Bundle required libraries with the Tahoe distribution so that if someone downloads the distribution, moves to a desert island without a net connection, and then installs, it works.

setuptools

We use a Python packaging tool named setuptools.

Advantages:

  • management of dependencies (even on platforms that don't have a native package manager); This is the important feature.
  • for hackers who like setuptools, this makes using Tahoe convenient and pleasant for them

Possible advantages:

  • perhaps in the future we will replace "build/configure/package/distribute/test/develop" code written in the Make language with code written in Python; One specific instance of this is ./setup.py test which runs the unit tests