|Building Packages with git-buildpackage suite: Version: 0.7.0-tizen20151027|
The gbp buildpackage-rpm tool is used for building.
The tool creates the source tarball and copies it and the packaging files
to a separate build directory and builds the package there. By default,
rpmbuild is used as the builder command. You can define a different
builder command with the
To build the (non-native) package when on packaging-branch, using pristine-tar to create upstream tarball:
$ gbp buildpackage-rpm --pristine-tarDuring development, if you have unclean git tree (untracked files and/or uncommitted changes) you may use:
$ gbp buildpackage-rpm --git-ignore-untrackedor:
$ gbp buildpackage-rpm --git-ignore-new
Git-buildpackage-rpm always builds in a separate build directory (./rpmbuild/ by default). You may change that and also build a different revision that your current branch HEAD. The revision can be any git "commit-ish", i.e. branch or tag name or a commit sha1. Git-buildpackage also supports some "special revisions", i.e. INDEX refer to the current index, WC or WC.IGNORED refer to the current working copy with all (even untracked and ignored) files, WC.TRACKED refers to the current working copy of the files tracked by git, WC.UNTRACKED refers to the current working copy of all files excluding ignore files. Some examples:
$ gbp buildpackage-rpm --git-export-dir=/home/user/rpmbuild $ gbp buildpackage-rpm --git-export-dir=/home/user/rpmbuild --git-export=v1.2.3 $ gbp buildpackage-rpm --git-export=WC.UNTRACKED $ gbp buildpackage-rpm --git-export=INDEX $ gbp buildpackage-rpm --git-export=feature/cool-new-thing $ gbp buildpackage-rpm --git-export=8d55173610f
When developing a non-native package with packaging and sources
in the same branch
(see Non-native package, model 1)
you usually want for gbp buildpackage-rpm to automatically generate
patches. In this mode, gbp buildpackage-rpm generates the upstream
tarball and copies packaging files to the build dir. After that it
generates patches from commits between
upstream and the
revision to be built, and, updates the spec file accordingly.
Git-buildpackage-rpm also have some options to alter the patch
generation. Build package with patch generation:
$ gbp buildpackage-rpm --git-patch-exportIgnore changes to packaging/ directory and compress patches larger than 100 kilobytes:
$ gbp buildpackage-rpm --git-patch-export --git-patch-export-compress=100k --git-patch-export-ignore-path='^packaging/.*'
When developing a non-native package with packaging data and source code in separate branches (see Non-native package, model 2) you use the gbp pq-rpm tool to handle the patches. You work on the source code on the development branch and then export the patches to the packaging branch when building the RPM package.
Create a development (or patch-queue) branch by applying the patches in current packaging branch on top of the upstream version. This will create a new branch, e.g. development/master assuming your current branch is master. Simply:
$ gbp pq-rpm importNow you can develop normally on the development branch (add, remove, rebase, amend commits). Just make sure you stay based on the correct upstream version, if doing git-rebase. After you're happy with your changes and you're ready to build an RPM package, you have to export the patches with gbp pq-rpm. This will change back to you packaging branch, generate patches from commits between between upstream and the HEAD of the development branch and update the spec file with the new patches:
$ gbp pq-rpm exportCommit the changes to packaging branch, and build. For example:
$ git add *patch *spec $ git commit -a $ gbp buildpackage-rpmOf course you can build even without committing by using the
--git-export=WC.UNTRACKEDoption of gbp buildpackage-rpm.
Moving to a new upstream version is basically simple. Assuming you have imported/pulled new upstream version to your git-tree, just:
$ git checkout master # Edit the spec file and change the 'Version:' tag to new upstream version $ vim *spec $ git commit *spec $ gbp pq-rpm rebaseHowever, if the patches do not apply cleanly, you have to manually apply and resolve the patches.
|<<< Development flow||Command Reference >>>|