Differences between revisions 26 and 27
Revision 26 as of 2013-12-07 19:16:35
Size: 7146
Comment: Add git-import-orig --uscan
Revision 27 as of 2014-03-12 22:28:27
Size: 7326
Comment:
Deletions are marked like this. Additions are marked like this.
Line 145: Line 145:
 * [[cowbuilder]] may also be useful  * [[cowbuilder]] and [[git-pbuilder]] may also be useful
Line 156: Line 156:
 * [[http://people.debian.org/~debalance/packaging-with-git.html|Co-maintaining a Debian package with git, git-buildpackage and pbuilder]] by Philipp Huebner

Translation(s): English - Italiano


Packaging with Git

{i} Note, that this is just a very general introductory guide. Full, official documentation can be found in the git-buildpackage package (see online documentation).

For help converting Subversion repositories created by svn-buildpackage to git, see the svn-buildpackage conversion subpage.

You should also read about pristine-tar support below.

This page describes the workflow using the commands from the git-buildpackage package. Alternatively there is also git-dpm.

Getting started

It is easiest to first create the first version of a package, outside of Git. Once this is done, you should import the package using the git-import-dsc tool. The directory in which it is called will be the parent directory of the new Git repository.

$ git-import-dsc /path/to/package_0.1-1.dsc

This will give output of its progress and make a few commits. Afterwards, you will have some new files and directories:

$ ls
package/
package_0.1-1.orig.tar.gz

Looking in the new repository shows git-buildpackage has done the following:

  • Imported the package files (but not debian/ directory) into the upstream branch

  • This has then been tagged upstream/0.1 where 0.1 is your package's version number

  • Imported the debian/ directory into master as well as upstream's files

  • Tagged the last commit as debian/0.1-1 as it assumes the package is finished.

Further packaging workflow

Now you can work in the master branch to edit the package. Commit with:

$ git commit -a

and build the package with:

$ git-buildpackage

Once you have produced a release-ready package, you should tag it, in the following way:

$ git-buildpackage --git-tag

Make sure that your debian/changelog file is correct, as that is what will be used to create the tag. The tag will be named debian/0.1-2 where 0.1-2 is the Debian version.

Upgrading to new upstream version

When a new upstream version comes out, use the git-import-orig tool to add it to the repository.

Using a debian/watch file (recommended)

$ git-import-orig --uscan

Using a tarball file

$ git-import-orig /path/to/new-upstream.tar.gz -u 0.2

where 0.2 is the new upstream version number.

{i} If the upstream tarball is already in the form packagename_version.orig.tar.gz (E.g. package_0.2.orig.tar.gz), then the -u option is not required.

Merging a debian-experimental branch into master for sid

Lets assume you have have the following branches:

upstream

latest upstream in development

upstream-1.5

upstream's 1.5 series, considered stable

master

branch for building packages for sid

debian-experimental

branch for building packages for experimental

  • You are importing each point release into upstream-1.5 and merging to master
  • You are merging each beta release (1.6~beta) into upstream and merging to debian-experimental

At some point, you want to move the work from debian-experimental to the master branch and release it to unstable.

First, it is necessary to make sure debian-experimental has everything correct in debian/* - maybe you committed something on master and didn't cherry-pick it to debian-experimental. You can compare the debian/ subtrees like this:

git checkout master
git diff debian-experimental debian

If necessary, cherry pick any changes onto debian-experimental. The next merge will obliterate everything on master and replace it with the contents of the debian-experimental branch. The only thing that is kept is debian/changelog because it needs to reflect the change history within sid and does not need to contain details of individual releases to experimental. Here is how we do it (make sure master is a clean workspace):

git checkout master
git clean -fd && git checkout .
git merge -s ours debian-experimental
git diff --binary debian-experimental | git apply -R --index
git reset debian/changelog
git checkout debian/changelog
git commit -m 'Merge 1.6.0~rc1 from debian-experimental' --amend

After doing this, it is strongly suggested that you inspect the merge with gitk and with git diff before you push to alioth or any other developer. For example,

git diff debian-experimental

invoked in master should only show the changelog, because everything else on master should now be identical to debian-experimental.

Conclusion

That is all to the basics of building packages with Git! I would recommend making copies of packages and trying out the tools on temporary repositories, to start with. Once you feel you have mastered it, there are other options that should be looked at.

Further options

pbuilder

To use pbuilder, you must simply change builder in either ~/.gbp.conf or /etc/git-buildpackage/gbp.conf to /usr/bin/git-pbuilder

{i} /usr/bin/git-pbuilder can be edited to use additional options, such as --builddir and --debsign-k...

Signing tags

On calling either of the git-import-dsc or git-import-orig tools, the following options may be used:

--sign-tags

Whether to sign tags

--keyid=gpg-keyid

With what gpg key to sign tags with

pristine-tar

git-buildpackage also supports the use of pristine-tar, a new tool developed by Joey Hess to recreate identical tarballs from a small delta file and the files in the current directory.

If you enable pristine-tar, delta files are committed to a pristine-tar branch if you call git-import-dsc or git-import-orig. When you build the package using git-buildpackage, the exact tarball is regenerated using pristine-tar.

On calling either of the git-import-dsc or git-import-orig tools, the --pristine-tar option may be used. On calling git-buildpackage, the --git-pristine-tar option may be used. You may also enable the pristine-tar option /etc/git-buildpackage/gbp.conf.

See also