Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2010-08-08 10:41:45
Size: 1718
Editor: ?BernhardRLink
Comment: Begin description of git-dpm.
Revision 5 as of 2010-08-08 11:38:40
Size: 3717
Editor: ?BernhardRLink
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * Look as similar as results from Debian tools as possible
  The result of an git clone should be similar enough to the source package unpacked with dpkg-source -x,
  so one can point users not familar with git or git-dpm to the version stored in git to be able to test
  unfinished versions. Allow removal of files in the debian branch relatively to the upstream branch to
  support the traditional way of removing files modified by the build process in debian/rules clean.
Line 29: Line 34:
TBW You can either [[PackagingWithGit/GitDpm/ImportDsc|import .dsc files]] or [[PackagingWithGit/GitDpm/Initialize|start from scratch]].
Line 33: Line 38:
TBW ==== Build a package ====
Line 35: Line 40:
{{{
git-dpm prepare && dpkg-buildpackage -rfakeroot -us -uc
}}}
Line 36: Line 44:
       will check everything is ready (possibly checking out a missing .orig.tar file using pristine tar) and then build
it. (Usually it should suffice to just place the .orig.tar file in the parent directory and call {{{dpkg-buildpackage}}},
but git-dpm prepare will make sure you are not in the middle of some change and the correct .orig.tar file is there).

==== Add a patch ====

To write a patch yourself:

{{{
git-dpm checkout-patched
vim files
git commit -a
git-dpm update-patches
}}}

Include a patch file

{{{
git-dpm apply-patch patchfile
git-dpm update-patches
}}}

Cherry pick a commit from upstream:

{{{
git-dpm apply-patch patchfile
git-dpm update-patches
}}}

(You of course only need the update-patches command once you are done and not
if you want to add more stuff or edit any of the patches afterwards).

==== other stuff ====

to be continued ...

== shortcomings ==
 * As git-dpm is quite new, it usually misses many of the nice gimmicks and some of the automatisms the
 tools from the git-buildpackage family offer.
 * multiple upstream tarballs are not yet supported (but should be no big problem to add).
 * documentation is horrible (your humble author is bad at writing documentation even beyond the usual non-native speaker's inability to do so)

Maintaining Debian source packages in git with git-dpm

This page describes how to use git-dpm. For instructions how to use the git-buildpackage family of commands, look at PackagingWithGit.

design goals

The main design goals are:

  • Make the generated source packages dsc format 3.0 (quilt).

    • So users unpacking the source packages from their CD or one of the Debian mirrors

      can easily evaluate the modifications and also look at them at patch-tracker. When they unpack a package with dpkg-source they get the final source (no understanding of any patch system needed).

  • Store the patches as permanent git commits.
    • Patches are imported at most once and then live as git commits and are edited with git methods (amend, rebase, ...). No repeated translation from patch to commit back to patch back to commit. Upstream or people from other distributions can just cherry-pick patches from your repository.
  • Contain all information in one branch that can pushed and pulled fast-forwardly.
    • While git rebase -i is the better quilt, git has no easy way to collaborate on such a branch or to retain its history. That's why in a git-dpm based workflow the patched branch is not published as git branch but only as a merged part of the history.
  • Look as similar as results from Debian tools as possible
    • The result of an git clone should be similar enough to the source package unpacked with dpkg-source -x, so one can point users not familar with git or git-dpm to the version stored in git to be able to test unfinished versions. Allow removal of files in the debian branch relatively to the upstream branch to support the traditional way of removing files modified by the build process in debian/rules clean.

documentation

As with most tool, documentation can always be improved. Currently there is some on the git-dpm website. I hope this page will also get some more examples and explanations added.

How to start

You can either import .dsc files or start from scratch.

Common operations

Build a package

git-dpm prepare && dpkg-buildpackage -rfakeroot -us -uc

will check everything is ready (possibly checking out a missing .orig.tar file using pristine tar) and then build it. (Usually it should suffice to just place the .orig.tar file in the parent directory and call dpkg-buildpackage, but git-dpm prepare will make sure you are not in the middle of some change and the correct .orig.tar file is there).

Add a patch

To write a patch yourself:

git-dpm checkout-patched
vim files
git commit -a
git-dpm update-patches

Include a patch file

git-dpm apply-patch patchfile
git-dpm update-patches

Cherry pick a commit from upstream:

git-dpm apply-patch patchfile
git-dpm update-patches

(You of course only need the update-patches command once you are done and not if you want to add more stuff or edit any of the patches afterwards).

other stuff

to be continued ...

shortcomings

  • As git-dpm is quite new, it usually misses many of the nice gimmicks and some of the automatisms the tools from the git-buildpackage family offer.
  • multiple upstream tarballs are not yet supported (but should be no big problem to add).
  • documentation is horrible (your humble author is bad at writing documentation even beyond the usual non-native speaker's inability to do so)