On Mon, Sep 25, 2017 at 09:22:07AM +0200, Peter Van Eynde wrote: > > BTW, the git repository of clisp packaging is rather complex with many > > different branches (even one branch per release recently), making the > > git-buildpackage workflow uneasy. > > My workflow predates a lot of the tooling available now...
> I could not find another way of having ‘clean’ patches against upstream then
> by doing a ‘git rebase’ when a new upstream release comes out.
The typical master/upstream repository layout is the following:
- the upstream branch contains successive versions of the upstream source; no
debian packaging on this branch
- the master branch contains the unpacked debian package (i.e. upstream +
debian/ subdirectory); this is where you commit your changes to the
packaging; upstream is periodically merged into master when a new release is
to be packaged
Graphically, it looks like:
^ ^
| |
debian/1.1-1 |
| |
+ |
|`---------------+
| |
| upstream/1.1
| |
debian/1.0-2 |
| |
debian/1.0-1 |
| |
+ |
|`---------------+
| |
| upstream/1.0
| |
^ ^
master upstream
Using another branch is not frequent, but you may want to do so whenever there
is a branching in the history of Debian version numbers.
For example if you make a stable upload (with a "+deb9u1"), this conceptually
corresponds to a fork in the Debian version history, so you create a new branch
(e.g. named "stretch") that forks master a the corresponding point (but the
"stretch" branch is never meant to be merged back into master).
Similarly, if you maintain in parallel two major releases (one in unstable, the
other one in experimental), then you want a new git branch. In this case it is
better to maintain the experimental version in master (because ultimately that
version is going to be the one in unstable), and the other version which stays
in unstable can go into a branch (e.g. named "<major-version>.x") that forks
master at the corresponding point (again, that branch is never meant to be
merged back into master, it will just die when the experimental version is
uploaded to unstable).
Finally there can be another branch, called pristine-tar, which shares no
history with the other ones, and that is used to keep some binary data which
enables someone to recreate a byte-to-byte identical orig tarball from the git
repository (using pristine-tar(1)). This branch is optional, but it is very
convenient, because it means that the git repository is self-contained, and you
(or someone else working on your package) does not risk a checksum problem on
the orig tarball when making an upload of a new debian revision.
> However if there is an easier and more standard way of doing things I would
> be all in favour of using if, provided that there is documentation in the
> form of ‘execute these commands’ to
>
> - create a build
> - create a new Debian release (go from -n to -n+1)
> - integrate a new upstream release
I describe below a git workflow that uses the git-buildpackage tool:
1. Import a new upstream version with:
$ gbp import-orig --pristine-tar <package>_<version>.orig.tar.gz
This does 4 things:
- update the upstream branch with a new commit containing the diff
corresponding to the new upstream version
- create an upstream/<version> tag
- merge upstream into master
- update the pristine-tar branch with the right binary blob
2. Work on the packaging by making commits on the master branch. Do not update
debian/changelog in the process, but format your git commits using special
fields in the git commit message, in particular for closing bugs (see
gbp-dch(1))
3. Test your packaging:
3.1. Generate an UNRELEASED changelog entry
$ gbp dch --auto --snapshot
(or short form: "gbp dch -a -S")
3.1. Build the package without signing it, and without warning about
uncommitted changes:
$ gbp buildpackage --git-pristine-tar --git-ignore-new -us -uc
Underneath this will call debuild.
4. Possibly make other changes
5. Once you're happy, prepare the upload
5.1. Finalize the changelog with
$ gbp dch --auto --release
(or short form: "gbp dch -a -R")
5.2. Compile the package, sign the upload and create the debian/<version> tag
with:
$ gbp buildpackage --git-pristine-tar --git-tag
If like me you use "sbuild" instead of "debuild" when making an upload,
you can add the following option: --git-builder=sbuild; or you can use
cowbuilder with the --git-pbuilder option.
5.3. Upload the result
6. For creating a new Debian revision, go to 2.
For packaging a new upstream version, go to 1.
A variant of this workflow does not use "gbp dch" for creating the changelog,
but rather populates debian/changelog gradually with each new commit. This is
perflectly possible, and may facilitate for you the transition to this workflow
since this is what you are used to. But I consider this to be inferior since it
makes the manipulation of the git history much more difficult (you always get
conflicts on debian/changelog).
The use of the pristine-tar branch is also optional, just remove the
corresponding options in the above commands. But again it is very useful.
If you need to work on a branch different from master (for the reasons
enumerated above), create the branch using the usual git command ("git
branch"), then the --git-debian-branch=<branchname> option of "gbp
buildpackage" to build packages from that branch.
There are many other git workflows used in Debian, but the above one is
(according to my subjective perception) both the most popular and the easiest
to use.
You can find more ressources on git for packaging on this wiki page:
https://wiki.debian.org/GitPackagingWorkflow
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
signature.asc
Description: PGP signature
_______________________________________________ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
