7 | | The Bcfg2 project provides a `debian` subdirectory with the project's |
8 | | source that enables users to create their own Debian/Ubuntu compatible |
9 | | packages (`.deb` files). The steps to do this, assuming that you are |
10 | | running on a Debian/Ubuntu system, are as follows: |
11 | | |
12 | | === Install packages necessary for building bcfg2 === |
13 | | |
14 | | If the distribution you are building on already has packaged bcfg2 |
15 | | (even an older version), the following command will likely install the |
16 | | necessary packages to enable it to be built: |
| 8 | The Bcfg2 project provides a `debian` subdirectory with the project's source that enables users to create their own Debian/Ubuntu compatible packages (`.deb` files). The steps to do this, assuming that you are running on a Debian/Ubuntu system, are as follows: |
| 9 | |
| 10 | === Build deps === |
| 11 | |
| 12 | If the distribution you are building on already has packaged bcfg2 (even an older version), the following command will likely install the necessary packages to enable it to be built: |
29 | | === Install the Bcfg2 source code === |
30 | | |
31 | | Depending on which version of bcfg2 you want build, you can obtain the |
32 | | source code from [wiki:Download] or from the project's Subversion |
33 | | repository. To create a local anonymous working copy of the latest |
34 | | version of the bcfg2 source code, use a command like the following: |
| 24 | === Install source code === |
| 25 | |
| 26 | Depending on which version of bcfg2 you want build, you can obtain the source code from [wiki:Download] or from the project's Subversion |
| 27 | repository. To create a local anonymous working copy of the latest version of the bcfg2 source code, use a command like the following: |
40 | | === Configure the Bcfg2 working copy === |
41 | | |
42 | | Once you have a copy of the source code, there are a couple of final |
43 | | steps. |
44 | | |
45 | | First, Bcfg2 as packaged for Debian supports several different |
46 | | versions of Python. To select the appropriate version you will need |
47 | | to run the `buildsys-select.sh` script from within the `debian` |
48 | | subdirectory. You must pass it an argument ''<PYTHON_VERSION>'' that |
49 | | is one of the following values: |
| 33 | === Configure for python version === |
| 34 | '''This step is only needed in Bcfg2 1.0.0rc1 and earlier.''' |
| 35 | |
| 36 | Once you have a copy of the source code, there are a couple of final steps. |
| 37 | |
| 38 | First, Bcfg2 as packaged for Debian supports several different versions of Python. To select the appropriate version you will need |
| 39 | to run the `buildsys-select.sh` script from within the `debian` subdirectory. You must pass it an argument ''<PYTHON_VERSION>'' that is one of the following values: |
57 | | As Debian and other related distributions have matured, many of these |
58 | | are fading from use and the correct choice for ''<PYTHON_VERSION>'' is |
59 | | almost always `pycentral`. |
60 | | |
61 | | Once you have figured out the correct value for ''<PYTHON_VERSION>'', |
62 | | run the following command: |
| 47 | As Debian and other related distributions have matured, many of these are fading from use and the correct choice for ''<PYTHON_VERSION>'' is almost always `pycentral`. |
| 48 | |
| 49 | Once you have figured out the correct value for ''<PYTHON_VERSION>'', run the following command: |
69 | | The next step is to update the Debian `changelog` file with an |
70 | | appropriate package version string. Debian packages contain a version |
71 | | that is extracted from the latest entry in the `changelog` file. An |
72 | | appropriate version will help you distinguish your locally built |
73 | | package from one provided by your distribution. It also helps the |
74 | | packaging system know when a newer version of the package is available |
75 | | to install. |
76 | | |
77 | | It is possible to skip this step, but the packages you build will have |
78 | | the same version as the source distribution and will be easy to |
79 | | confuse with other similarly named (but maybe not equivalent) |
80 | | packages. |
| 56 | === Update the changelog === |
| 57 | |
| 58 | The next step is to update the Debian `changelog` file with an appropriate package version string. Debian packages contain a version |
| 59 | that is extracted from the latest entry in the `changelog` file. An appropriate version will help you distinguish your locally built |
| 60 | package from one provided by your distribution. It also helps the packaging system know when a newer version of the package is available to install. |
| 61 | |
| 62 | It is possible to skip this step, but the packages you build will have the same version as the source distribution and will be easy to |
| 63 | confuse with other similarly named (but maybe not equivalent) packages. |
101 | | If you are building from a local working copy of the Subversion |
102 | | repository, it is useful to include the repository revision in the |
103 | | package version. It will be a number like '5464'. If you are |
104 | | building from a downloaded copy of the source, drop this component |
105 | | (including the preceding plus-sign (`+`) from the package version |
106 | | string. |
| 78 | If you are building from a local working copy of the Subversion repository, it is useful to include the repository revision in the package version. It will be a number like '5464'. If you are building from a downloaded copy of the source, drop this component (including the preceding plus-sign (`+`) from the package version string. |
108 | | This is a locally relevant name like your last name or your domain |
109 | | name, plus the digit `1`. For example, if your family name is |
110 | | ''Smith'', you could use `smith1`. If you work for ''Example Inc'', |
111 | | you could use `example1`. |
| 80 | This is a locally relevant name like your last name or your domain name, plus the digit `1`. For example, if your family name is ''Smith'', you could use `smith1`. If you work for ''Example Inc'', you could use `example1`. |
115 | | * If you are building packages for revision 5463 of the Subversion |
116 | | trunk, and the latest published version is 1.0pre5, the version |
117 | | string should be `1.0~pre5+r5463-0.1+example1`. |
118 | | * If you are building packages for the published 1.0 rc1 version, the |
119 | | version string should be `1.0~rc1-0.1+example1`. |
120 | | * If you are building packages for the published 1.0 version, the |
121 | | version string should be `1.0-0.1+example1`. |
122 | | |
123 | | If you are working on a Subversion working copy of 1.0 pre5 and have |
124 | | the `devscripts` package installed, the following command is a |
125 | | convenient way to create a well formatted changelog entry: |
| 84 | * If you are building packages for revision 5463 of the Subversion trunk, and the latest published version is 1.0pre5, the version string should be `1.0~pre5+r5463-0.1+example1`. |
| 85 | * If you are building packages for the published 1.0 rc1 version, the version string should be `1.0~rc1-0.1+example1`. |
| 86 | * If you are building packages for the published 1.0 version, the version string should be `1.0-0.1+example1`. |
| 87 | |
| 88 | If you are working on a Subversion working copy of 1.0 pre5 and have the `devscripts` package installed, the following command is a convenient way to create a well formatted changelog entry: |