GITPKG(1) | General Commands Manual | GITPKG(1) |
gitpkg - export a Debian source package from nominated git revisions
gitpkg branch [origbranch]
If gitpkg is run in a git(1) repo with a single 'branch' specified, then it will do a git-archive export of that branch to the DEB_DIR directory. If the package is Debian native it will simply create a source package from it. If the package has a Debian version, then an orig tarball will be expected to already exist for it. If an orig tarball does not already exist then what happens next depends on the value of the gitpkg.create-fake-orig configuration option (described below).
If gitpkg is invoked with two branches specified, then the first branch will be exported as the unpacked complete source, while the second branch will be exported for the orig.tar.gz. This allows all local changes to the source to be recorded in the resulting diff.gz if a pristine upstream branch exists in the repository. If an orig tarball already exists for the version at 'branch' then what happens next depends on the value of the gitpkg.force-overwrite-orig configuration option (described below).
The 'branch' should always have a debian/ dir and may be any tree-ish object that is accepted by git-archive(1). The 'origbranch', if supplied, should usually not have a debian/ dir.
Almost all gitpkg configuration is handled using git-config(1) now. The following configuration options are supported:
gitpkg.orig-gz-opts
gitpkg.orig-xz-opts
gitpkg.orig-bz2-opts
User defined scripts can be invoked from a number of points during the package build process. They are sourced into gitpkg as bash shell snippets, in most cases in a subshell, so they can read state variables and perform external actions, but cannot alter the running configuration once a build is in progress. If a hook returns with a non-zero status, then gitpkg will be terminated. (Hooks that do terminate gitpkg should take some care not to leave too much of a mess, but also should leave enough clues intact for the user to diagnose and fix whatever the problem was. Useful and informative error messages should be barked to stderr before exiting in this way.)
Hook scripts may be installed on the host system outside of the repo tree, or sourced from version controlled files in the repo itself. Both methods have advantages and risks for different use cases. Hook scripts are activated by the local admin, by setting each relevant git-config(1) option with the path to the script to be executed. Paths may be absolute or relative to the directory which that hook is called from. If a hook is set, the script must exist when it is called. Care should be taken to only enable them for use by trusted source trees when hooking into files in the repo itself. Usually you should enable them on a per-repo basis with git-config(1) rather than at a --global or --system level.
You should avoid complicated in-package hook arrangements becoming essential for exporting your package source. If you need them to create a particular package correctly, and need strict version binding with the source being released, and they aren't useful to any other package at all ... then you're quite probably doing something, or several things, quite wrong. Else you're in such deep shit working around some broken build system that you don't need me to tell you about it. Either way, local admin has to enable your hooks before they can run, so if you want to be friendly to others (and yourself), then keep the 'normal' packaging work strictly inside the usual package building tools, and leave the gitpkg hooks free for other local admins to wrap whatever automation it is they need around things. If a particular version of the package source needs some particular actions performed on it prior to the first source package build, then the PREBUILD_TARGET option from above is most probably what you want rather than one of these hooks. Other people can use that again later without needing to have gitpkg around. The aim is for this to Help You. For some values of All Of You. So do be careful to avoid letting it screw other people over if the hook isn't called, and/or let them know what they need to do instead if it isn't. Ok then, there's the barb to watch out for, so back to the point again:
The available hook points are listed below in roughly the order that they would usually be invoked:
This hook is able to modify the gitpkg configuration variables for subsequent operations. It can perform operations on the repo if needed, but since it needs to be committed to the repo before it will ever be called, that may not be so useful here in practice. Basically, it can do anything it pleases, it's just a shell script, nothing else has really begun yet, and it has been sourced into the topmost shell level of gitpkg.
Its operation is different from the admin-config-hook in only one respect, the path to this hook must be relative to the TLD of the repo, and the revision of the file that will be sourced is checked out from the 'branch' tree-ish that gitpkg was requested to export. The file must exist in that version at the path given.
Available to hook scripts as PACKAGE_CONFIG_HOOK.
This can be used by the local admin to override any package specific options, that may have been set by the package-config-hook, with site specific configuration. This is a policy control, not a security one. Security was all over when you let the package-config-hook run, this just lets you override it without having to fake up a new commit changing the package hook.
This is the last hook to run that is able to modify the gitpkg configuration and set environment options that will be visible to later hooks. Available to hook scripts as ADMIN_CONFIG_HOOK. This may be overridden on the command line with the --admin-config-hook=path option.
This can be used to do things like invoke pristine-tar or prefetch an existing orig tarball from some foreign source. It may perform operations on the repo if any such are desired, or any other last minute check that needs to be done before we actually get about the task of exporting the source we want packaged.
Available to hook scripts as PRE_EXPORT_HOOK.
This hook is only invoked if the upstream 'origbranch' actually is exported from the repository. If an existing orig.tar is found or has been created by some earlier hook (and it is not being overwritten, see force-overwrite-orig above), then the operations this hook would perform are presumed to have already happened for this tarball and it is skipped.
It is not safe to assume that this hook will be executed before or after deb-export-hook, and it may in fact be run in parallel with it at some point in the future. They both will be entered after pre-export-hook returns, and exit-hook will not begin until (at least) after both have returned. What else happens in the middle of all that we make no firm promises about at this stage.
Available to hook scripts as ORIG_EXPORT_HOOK.
The following variables are made available for hook scripts, in addition to those already listed as shadowing a git-config option from above. Not all of them are valid/useful at all hook points, see the hook documentation above for the exceptions applying to specific hooks.
These variables have been available to hooks since gitpkg version 0.13
These variables have been available to hooks since gitpkg version 0.24
$ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz' Will give:
${GITPKG_AOPTS[my-option]} = "foo"
${GITPKG_AOPTS[option2]} = ""
${GITPKG_AOPTS[opt]} = "bar baz"
$ gitpkg --my-option=foo --option2 --opt=oops --opt='bar baz' Will give:
${GITPKG_IOPTS[0]} = "--my-option=foo"
${GITPKG_IOPTS[1]} = "--option2"
${GITPKG_IOPTS[2]} = "--opt=oops"
${GITPKG_IOPTS[3]} = "--opt=bar baz"
The extract_values_for_option function in repo-config-helper (see below for details of it) can be used to further parse this array to obtain all the value(s) for a specific option.
There are some canned hook scripts for various tasks available in /usr/share/gitpkg/hooks which currently include:
$ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/cowpoke-exit-hook
Additional git-config(1) configuration options:
$ git config gitpkg.exit-hook /usr/share/gitpkg/hooks/dpkg-buildpackage-exit-hook
Additional git-config(1) configuration options:
$ git config gitpkg.pre-export-hook /usr/share/gitpkg/hooks/pristine-tar-pre-export-hook
If a pristine-tar branch is not found in the repo, then gitpkg will be terminated.
To enable it:
$ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook
The contents of debian/source/git-patches may include comments (on any line beginning with a #), empty lines, and expressions of a range of commits. The revision ranges may include $DEB_VERSION, $UPSTREAM_VERSION, $DEB_REF or $UPSTREAM_REF. The first pair will be substituted with the version of the package being exported, the second pair with those version strings after mangling by sanitise_git_ref to remap them to a legal git refname. Using the sanitised versions is to be preferred in most cases. For example:
# Export all commits between these two treeishes,
# based on the version of the package being exported.
upstream/$UPSTREAM_REF..patches/$DEB_REF
To enable it:
$ git config gitpkg.deb-export-hook /usr/share/gitpkg/hooks/debcherry-deb-export-hook
In order to use this hook, a ${DEB_ORIG}.commit file must be created which contains the treeish of the exported upstream source in the repository. This will be created automatically (if this hook is enabled) when you export an upstream tarball by passing both branch and origbranch to gitpkg, or if you use the pristine-tar-pre-export-hook, which determines an appropriate commit corresponding to the tarball. If your upstream tarball is created using some other mechanism you will need to ensure that file is created yourself.
If using this hook, you may wish to document that in your repository with something similar to the text in /usr/share/doc/gitpkg/examples/README.debcherry-export as a convenience to other users. Your package will still be exportable without this hook enabled, it just won't have the upstream patches individually separated out into a quilt series.
These are even more trivial snippets, for operations which may be shared by several scripts. Also found in /usr/share/gitpkg/hooks. Usually these would be sourced by other scripts rather than being hooked to directly.
Provides the sanitise_git_ref shell function which remaps character strings that are illegal to use in a git refname.
Provides the extract_values_for_option shell function which can be used to extract an array of the values for a particular option from GITPKG_IOPTS.
See the content of that file itself for more detailed documentation on the functions that it provides.
If you intend to call gitpkg from your own scripts, then you should note that there are two situations when it may prompt interactively by default. There is no One True Sane Default for these cases, so it's better to just ask the user and continue than to make them start the whole process again in the likely case where they have called gitpkg directly. For details, see the gitpkg.force-overwrite-orig and gitpkg.create-fake-orig config options above. You should set both explicitly to the behaviour that you desire from them if gitpkg should never become interactive.
Though gitpkg explicitly does not try to force any particular workflow procedure upon you in order to make full use of it, it probably is worth making quick mention of at least one simple way to manage Debian packages in git.
One common repo structure is to keep pristine upstream source on one branch, which is updated either directly from an upstream repo or by importing tar archives to it periodically, with the Debian patched source on another branch. In this situation the task of preparing a new upstream release from a tarball might look a bit like this:
Check out the upstream branch
$ cd myrepo
$ git checkout upstream
Remove all old upstream files from the repo
$ rm -rf $(all_files_except .git)
Unpack the new tarball in their place
$ tar zxf $new_upstream.tar.gz
Let git figure out what is renamed/new/gone by itself.
Make sure you don't have things like vim .swp files lurking
in the tree still at this point.
$ git add .
$ git commit -a
$ git tag v$upstream_version
Prepare the Debian branch
$ git checkout debian
$ git merge upstream
$ $(update changelog and other debian patches etc.)
$ git commit -a
$ git tag v${upstream_version}-$debian_version
Make a release
$ gitpkg v${upstream_version}-$debian_version v$upstream_version
$ cd ../deb-packages/mypackage && dpkg-buildpackage ...
git-debimport(1), git-debcherry(1), git(1), git-archive(1), git-config(1), git-format-patch(1), gitattributes(5), dpkg-source(1), cowpoke(1).
gitpkg was written by Ron <ron@debian.org>.
March 18, 2018 |