4 | | * Install packages necessary for building bcfg2 [[BR]] |
5 | | {{{apt-get build-dep bcfg2 bcfg2-server}}} [[BR]] |
6 | | or, if the available repositories do not have any version of bcfg2, try something like: [[BR]] |
7 | | {{{apt-get install cdbs docbook-xsl libxslt1.1 python-dev python2.4-dev sgml-base xml-core xsltproc fakeroot}}} |
8 | | * Untar the sources - or for bleeding edge, {{{svn co https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2}}} |
9 | | * cd into the debian/ subdirectory |
10 | | * Optional: if you want to have a special name for your own package, edit the first line of changelog: change eg. "(0.9.5.7-0.1)" to "(0.9.5.7-0.1myname)" |
11 | | * run ./buildsys-select.sh <python version> [[br]]This will setup the package to install python properly. [[br]] |
12 | | <python version> is either: |
13 | | * 2.3 (for debian sarge), |
14 | | * 2.4 (for breezy, dapper, and nexenta <= alpha 6) |
15 | | * pycentral (for etch, feisty and edgy, gutsy, hardy). |
16 | | |
17 | | * cd .. |
18 | | * run "fakeroot dpkg-buildpackage -uc -us" |
19 | | * enjoy your freshly built packages |
20 | | |
| 4 | |
| 5 | The Bcfg2 project provides a `debian` subdirectory with the project's |
| 6 | source that enables users to create their own Debian/Ubuntu compatible |
| 7 | packages (`.deb` files). The steps to do this, assuming that you are |
| 8 | running on a Debian/Ubuntu system, are as follows: |
| 9 | |
| 10 | === Install packages necessary for building bcfg2 === |
| 11 | |
| 12 | If the distribution you are building on already has packaged bcfg2 |
| 13 | (even an older version), the following command will likely install the |
| 14 | necessary packages to enable it to be built: |
| 15 | |
| 16 | {{{ |
| 17 | apt-get build-dep bcfg2 bcfg2-server |
| 18 | }}} |
| 19 | |
| 20 | Or, if the available repositories do not have any version of bcfg2, |
| 21 | try something like: |
| 22 | |
| 23 | {{{ |
| 24 | apt-get install cdbs docbook-xsl libxslt1.1 python-dev python2.4-dev sgml-base xml-core xsltproc fakeroot |
| 25 | }}} |
| 26 | |
| 27 | === Install the Bcfg2 source code === |
| 28 | |
| 29 | Depending on which version of bcfg2 you want build, you can obtain the |
| 30 | source code from [wiki:Download] or from the project's Subversion |
| 31 | repository. To create a local anonymous working copy of the latest |
| 32 | version of the bcfg2 source code, use a command like the following: |
| 33 | |
| 34 | {{{ |
| 35 | svn co https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2 bcfg2-trunk |
| 36 | }}} |
| 37 | |
| 38 | === Configure the Bcfg2 working copy === |
| 39 | |
| 40 | Once you have a copy of the source code, there are a couple of final |
| 41 | steps. |
| 42 | |
| 43 | First, Bcfg2 as packaged for Debian supports several different |
| 44 | versions of Python. To select the appropriate version you will need |
| 45 | to run the `buildsys-select.sh` script from within the `debian` |
| 46 | subdirectory. You must pass it an argument ''<PYTHON_VERSION>'' that |
| 47 | is one of the following values: |
| 48 | |
| 49 | `2.3`:: for Debian sarge. |
| 50 | `2.4`:: for Ubuntu breezy, dapper, and Nexenta <= Alpha 6. |
| 51 | `pycentral`:: |
| 52 | for Debian etch or newer; Ubuntu edgy, feisty, gutsy, and hardy or |
| 53 | newer. |
| 54 | |
| 55 | As Debian and other related distributions have matured, many of these |
| 56 | are fading from use and the correct choice for ''<PYTHON_VERSION>'' is |
| 57 | almost always `pycentral`. |
| 58 | |
| 59 | Once you have figured out the correct value for ''<PYTHON_VERSION>'', |
| 60 | run the following command: |
| 61 | |
| 62 | {{{ |
| 63 | cd bcfg2-trunk/debian |
| 64 | ./buildsys-select.sh <PYTHON_VERSION> |
| 65 | }}} |
| 66 | |
| 67 | The next step is to update the Debian `changelog` file with an |
| 68 | appropriate package version string. Debian packages contain a version |
| 69 | that is extracted from the latest entry in the `changelog` file. An |
| 70 | appropriate version will help you distinguish your locally built |
| 71 | package from one provided by your distribution. It also helps the |
| 72 | packaging system know when a newer version of the package is available |
| 73 | to install. |
| 74 | |
| 75 | It is possible to skip this step, but the packages you build will have |
| 76 | the same version as the source distribution and will be easy to |
| 77 | confuse with other similarly named (but maybe not equivalent) |
| 78 | packages. |
| 79 | |
| 80 | The basic format of the package version string to use is this: |
| 81 | |
| 82 | {{{<UPSTREAM VER>~<UPSTREAM PRE-VER>+r<UPSTREAM SVN REV>-0.1+<LOCAL VER>}}} |
| 83 | |
| 84 | '''NOTE: The '~', '+', and '-' characters have significance in |
| 85 | determining when one package is newer than another. The following |
| 86 | format is believed to do the right thing in all common situations.''' |
| 87 | |
| 88 | The components of the package version string are explained below: |
| 89 | |
| 90 | `<UPSTREAM VER>`:: |
| 91 | This is the version of the Bcfg source code you are working from. |
| 92 | It will likely be something like `0.9.6` or `1.0`. |
| 93 | `~<UPSTREAM PRE-VER>`:: |
| 94 | If you are using a published pre-release of Bcfg2, it will have a |
| 95 | name like `pre1` or `rc1`. Use that string here, otherwise drop |
| 96 | this component and the preceding tilde (`~`) character from the |
| 97 | package version string. |
| 98 | `+<UPSTREAM SVN REV>`:: |
| 99 | If you are building from a local working copy of the Subversion |
| 100 | repository, it is useful to include the repository revision in the |
| 101 | package version. It will be a number like '5464'. If you are |
| 102 | building from a downloaded copy of the source, drop this component |
| 103 | (including the preceding plus-sign (`+`) from the package version |
| 104 | string. |
| 105 | `+<LOCAL VER>`:: |
| 106 | This is a locally relevant name like your last name or your domain |
| 107 | name, plus the digit `1`. For example, if your family name is |
| 108 | ''Smith'', you could use `smith1`. If you work for ''Example Inc'', |
| 109 | you could use `example1`. |
| 110 | |
| 111 | Here are some examples: |
| 112 | |
| 113 | * If you are building packages for revision 5463 of the Subversion |
| 114 | trunk, and the latest published version is 1.0pre5, the version |
| 115 | string should be `1.0~pre5+r5463-0.1+example1`. |
| 116 | * If you are building packages for the published 1.0 rc1 version, the |
| 117 | version string should be `1.0~rc1-0.1+example1`. |
| 118 | * If you are building packages for the published 1.0 version, the |
| 119 | version string should be `1.0-0.1+example1`. |
| 120 | |
| 121 | If you are working on a Subversion working copy of 1.0 pre5 and have |
| 122 | the `devscripts` package installed, the following command is a |
| 123 | convenient way to create a well formatted changelog entry: |
| 124 | |
| 125 | {{{ |
| 126 | REV=$(svn info|grep '^Revision' |cut -d' ' -f2) |
| 127 | debchange --force-bad-version --preserve --newversion "1.0~pre5+r${REV}-0.1+example1" SVN revision $REV |
| 128 | }}} |
| 129 | |
| 130 | === Building the Bcfg2 Package === |
| 131 | |
| 132 | With the preliminaries out of the way, building the package is simple. |
| 133 | |
| 134 | {{{ |
| 135 | cd .. # Change into the top level of the source directory |
| 136 | fakeroot dpkg-buildpackage -uc -us |
| 137 | }}} |
| 138 | |
| 139 | The freshly built packages will be deposited in the parent of the |
| 140 | current directory (`..`). Examine the output of `dpkg-buildpackage` |
| 141 | for details. |
| 142 | |