| 5 | | = Packaging = |
| | 5 | = Build Types and Goals = |
| | 6 | |
| | 7 | == Novice User == |
| | 8 | |
| | 9 | In this build type, a user downloads the Tahoe-LAFS source and everything is as automatic as possible. Internet access is assumed, and there is nothing wrong with using it. |
| | 10 | |
| | 11 | == Developer == |
| | 12 | |
| | 13 | In this build type, someone would like to make changes to Tahoe-LAFS, and gets source from git. TODO |
| | 14 | |
| | 15 | == Packaging System == |
| | 16 | |
| | 17 | In this build type, the build user is a packager of rpms/debs or pkgsrc. Rather than convenience, the concern is a stable and repeatable build that produces exactly the same output bits regardless of which prereqs were already installed. Using the network is not acceptable. |
| | 18 | |
| | 19 | Within a packaging system, there are typically build phases, loosely derived from how autoconf works. |
| | 20 | |
| | 21 | * fetch: obtain the "distfiles" (tarballs published by e.g. the tahoe project) |
| | 22 | * patch: apply OS-local/pkgsrc-local changes (goal is to drive these to zero) |
| | 23 | * configure: search for dependencies and configure paths |
| | 24 | * build: compile sources to object form, run nroff to make man pages, etc. |
| | 25 | * install: place bits either in the running system or in a destdir, suitable for running |
| | 26 | * package: create a binary package from the installed bits |
