Skip to content

Latest commit

 

History

History
76 lines (63 loc) · 3.83 KB

debian.rst

File metadata and controls

76 lines (63 loc) · 3.83 KB

Debian Packaging

Release Publishing

Note

The Debian package release is made only after the upstream release has been tagged.

After a C driver release is completed (i.e. the :ref:`releasing.jira` step of the release process), a new Jira ticket will be automatically created to track the work of the corresponding release of the Debian package for the C driver (example ticket).

To publish a new release Debian package, perform the following:

  1. Change to the packaging branch, git checkout debian/unstable, and make sure the working directorty is clean, git status, and up-to-date, git pull.
  2. Because it is possible to have divergences between release branches, some special procedures are needed. Execute the following sequence of commands (substituting version numbers as appropriate):
$ git merge --no-commit --no-ff 1.xx.y       # may result in conflicts
$ git checkout HEAD -- debian                # ensures debian/ dir is preserved
$ git add .                                  # prepare to resolve conflicts
$ git checkout --no-overlay 1.xx.y -- . ':!debian'   # resolve conflicts
$ git add .
$ git commit

  1. Verify that there are no extraneous differences from the release tag, git diff 1.xx.y..HEAD --stat -- . ':!debian'; the command should produce no output, and if any output is shown then that indicates differences in files outside the debian/ directory.

  2. If there were any files outside the debian/ directory listed in the last step then something has gone wrong. Discard the changes on the branch and start again.

  3. Create a new changelog entry (use the command dch -i to ensure proper formatting), then adjust the version number on the top line of the changelog as appropriate.

  4. Make any other necessary changes to the Debian packaging components (e.g., update to standards version, dependencies, descriptions, etc.) and make relevant entries in debian/changelog as needed.

  5. Use git add to stage the changed files for commit (only files in the debian/ directory should be committed), then commit them (the debcommit utility is helpful here).

  6. Build the package with gbp buildpackage and inspect the resulting package files (at a minimum use debc on the .changes file in order to confirm files are installed to the proper locations by the proper packages and also use lintian on the .changes file in order to confirm that there are no unexpected errors or warnings; the lintian used for this check should always be the latest version as it is found in the unstable distribution).

  7. If any changes are needed, make them, commit them, and rebuild the package.

    Note

    It may be desirable to squash multiple commits down to a single commit before building the final packages.

  8. Mark the package ready for release with the dch -r command, commit the resulting changes (after inspecting them), git commit debian/changelog -m 'mark ready for release'.

  9. Build the final packages. Once the final packages are built, they can be signed and uploaded and the version can be tagged using the --git-tag option of gbp buildpackage. The best approach is to build the packages, prepare everything and then upload. Once the archive has accepted the upload, then execute gbp buildpackage --git-tag --git-tag-only --git-sign-tags and push the commits on the debian/unstable branch as well as the new signed tag.