Chapter 10. Packaging with git

It is highly desirable to host Debian source code package on Salsa. Over 90% of all Debian source code packages are hosted on Salsa. ^[20]

The exact VCS repository hosting an existing Debian source code package can be identified by a metadata field Vcs-* which can be viewed with the apt-cache showsrc <package-name> command.

After signing up for an account on Salsa, make sure that the following pages have the same e-mail address and GPG keys you have configured to be used with Debian, as well as your SSH key:

Salsa runs Salsa CI service as an instance of GitLab CI for “Section 9.4, “持续集成””.

For every “git push” instances, tests which mimic tests run on the official Debian package service can be run by setting Salsa CI configuration file “Section 6.13, “debian/salsa-ci.yml file”” as:

---
include:
  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml

# Customizations here

In this tutorial, old style branch names are used in examples for simplicity.

	Note
	This upstream-branch may need to be created using the tarball released by the upstream independent of the upstream Git repository since it tends to contain automatically generated files.

The upstream Git repository content can co-exit in the local Git repository used for the Debian packaging by adding its copy. E.g.:

$ git remote add upstream-git <url-upstream-git-repo>
$ git fetch upstream-git master:upstream-master

This allows easy cherry-picking from the upstream Git repository for bug fixes.

Package history management with the git-buildpackage package is becoming the standard practice for many Debian maintainers. See more at:

The new dgit package offers commands to automate packaging activities using the git repository as an alternative to still popular gbp-buildpackage. Please read their guide:

The dgit(1) command can push the easy-to-trace change history to the https://browse.dgit.debian.org/ site and can upload Debian package to the Debian repository properly without using dput(1).

The concept around dgit is beyond this tutorial document. Please start reading relevant information:

For “Section 10.5, “Patch unapplied Git repository””, you can generate debian/patches/* files using the gbp-pq(1) command from git commits in the through-away patch-queue branch.

Unlike dquilt which offers similar functionality as seen “Section 5.11, “Patch by dquilt approach”” and “Section 8.5, “Manage patch queue with dquilt””, gbp-pq doesn’t generate .pc/* files.

If the package is managed in “Section 10.5, “Patch unapplied Git repository”” using the git-buildpackage package, you can revise the upstream source to fix bug as the maintainer and release a new Debian revision using gbp pq.

For Debian source packages named “<source-package>” recorded in the snapshot.debian.org archive, an initial git repository managed in “Section 10.5, “Patch unapplied Git repository”” with all of the Debian version history can be generated as follows.

$ gbp import-dscs --debsnap --pristine-tar <source-package>

Here are some hints around dgit-maint-debrebase(7). ^[21]

See dgit-maint-debrebase(7), dgit(1) and git-debrebase(1) for more.

The quasi-native packaging scheme packages a source without the real upstream tarball using the non-native package format.

	Tip
	Some people promote this quasi-native packaging scheme even for programs written only for Debian since it helps to ease communication with the downstream distros such as Ubuntu for bug fixes etc.

This quasi-native packaging scheme involves 2 preparation steps:

The rest is the same as the non-native packaging workflow as written in “Section 6.1, “打包工作流””.

Although this can be done in many ways (“Section 15.4, “Snapshot upstream tarball (-d, -t)””), you can use the Git repository and “git deborig” as:

 $ cd /path/to/<dirname>
 $ dch -r
  ... set its <version>-<revision>, e.g., 1.0-1
 $ git tag -s debian/1.0-1
 $ git rm -rf debian
 $ git tag -s upstream/1.0
 $ git commit -m upstream/1.0
 $ git reset --hard HEAD^
 $ git deborig
 $ sbuild