wiki:Packaging

Version 9 (modified by warner, at 2007-08-21T23:59:59Z) (diff)

update section on debian packaging

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, we can 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.
    • For Ubuntu "edgy" and "feisty" platforms, as well as Debian "etch", 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
  • this covers all major debian-derived platforms released in the last year.

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.
  • 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

One option is to use a Python packaging tool named setuptools.

Advantages (note that each of these are options provided by setuptools, not requirements imposed by the use of setuptools):

  • management of dependencies (even on platforms that don't have a native package manager); This is the important feature.
  • for hackers who want to use Tahoe, and who like setuptools, this makes using Tahoe convenient and pleasant for them
  • 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

We already have a patch which changes Tahoe to use setuptools, but it doesn't solve the "How to integrate smoothly with platform-specific package managers." part yet.

related tickets

The primary ticket for tracking our progress on this issue:

#82 -- remove the "build" step in the "edit, build, run" cycle

Other related tickets:

#10 -- clean up after yourself when told to "make clean"

#47 -- use pyutil as a separate package and contribute src/allmydata/util/* into pyutil