| 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: |