Differences between revisions 3 and 4
Revision 3 as of 2010-09-28 04:49:02
Size: 3226
Comment:
Revision 4 as of 2011-02-18 04:20:36
Size: 2113
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
Still a proposal! In use for clisp.
Line 22: Line 22:
The `debian/` directory lives in the ''debian-<upstream version>'' branch. This branch is created new for every new upstream release and is rebased on the new release. So in practice you go: The `debian/` directory lives in the ''debian-<debian version>'' branch. This branch is created new for every new upstream release and is rebased on the new release. So in practice you go:
Line 29: Line 29:
git rebase --onto debian-2.49 upstream-2.49 debian-2.48
git checkout debian-2.49
git rebase --onto debian-2.49-1 upstream-2.49 debian-2.48-3
git checkout debian-2.49-1
Line 34: Line 34:
Patches and fixes to upstreams are in ''patch-<name>'' or ''typo-<name>'' branches of the respective upstream source. These are not rebased and should be forwarded to upstream. When patches or fixes are no longer needed in the ''master-sid'' branch they are deleted. Patches and fixes to upstreams are in quilt and live also in the debian-<version> branches.
Line 36: Line 36:
The real package itself is build on the ''master-sid'' branch, which is branched into the ''master-testing'' and ''master-<Debian release codename>'' when the package moves there.

The ''master-sid'' branch is recreated on each new upstream release like:

{{{
git branch -m master-sid master-<debian package version>
git checkout -b master-sid debian-<upstream version>
git pull . patch-<name>
git pull . patch-<name 2>
etc
}}}

If you discover a problem while working on preparing the ''master-sid'' branch you fix is in a new branch, for example if you have a build-failure on sparc due to a GCC bug you can do:

{{{
git checkout -b patch-sparc-gcc-bug-in-2.49 upstream-2.49
vi ...
git commit -a -m '...'
git checkout master-sid
git pull . patch-sparc-gcc-bug-in-2.49
}}}

Don't forget to forward this new patch to upstream.

You build using {{{git-buildpackage --git-debian-branch=master-sid --git-upstream-branch=upstream-<version> -us -uc}}}
You build using {{{git-buildpackage --git-debian-branch=debian-<debian version> --git-upstream-branch=upstream-<version> -us -uc}}}
Line 66: Line 42:
 * Do not change `debian/changelog` in the ''patches'' or ''typo'' branches, note the merge explicitly

Git usage in the Common Lisp packaging Team

In use for clisp.

Recommandations for handling the Git repository.

The Git repositories are stored on Alioth, for example for clisp we have:

  • web view

  • For people with Alioth access: git clone ssh://git.debian.org/git/pkg-common-lisp/clisp.git

  • Anonymous access either one of:
    • git clone http://git.debian.org/git/pkg-common-lisp/clisp.git

    • git clone git://git.debian.org/git/pkg-common-lisp/clisp.git

Repository setup

Upstream goes to a branch called upstream, each upstream version that is packages is also a branch upstream-<version>. The upstream for a released Debian version has a parallel branch called upstream-<Debian code name>, for example upstream-lenny.

The debian/ directory lives in the debian-<debian version> branch. This branch is created new for every new upstream release and is rebased on the new release. So in practice you go:

git checkout -b upstream-2.49 upstream-2.48
#import 2.49 here
git add ..
git commit ...
git rebase --onto debian-2.49-1 upstream-2.49 debian-2.48-3
git checkout debian-2.49-1
dch --newversion 2.49-1 --distribution UNRELEASED

Patches and fixes to upstreams are in quilt and live also in the debian-<version> branches.

You build using git-buildpackage --git-debian-branch=debian-<debian version> --git-upstream-branch=upstream-<version> -us -uc

Other Guidelines

  • Keep the distribution UNRELEASED until we release
  • Keep one commit to one consistent change, use git commit --amend in case you make mistakes

  • After each upload, the first commit should be creating a new changelog entry with distribution set to UNRELEASED
  • If upstream uses a SVC consider importing the upstream changes into the git tree.

NMU's and patches

NMU's are strongly encouraged to apply the changes directly into the git repositories.