This document is focused on how packit treats a source-git repo.
If you are looking for the design concept of source-git, please head on here: docs/source-git-design
In short, the source-git concept is fairly simple - take an upstream repo and shove downstream content on top of it. Easy right?
Packit is then able to work with such a repo and:
Sync the state into dist-git
And you are able to utilize all features of packit-service: builds on PRs, tests on those builds, update your package in Fedora.
Let’s describe all of these in detail.
Your source-git repo can contain upstream git history if you want. Or it doesn’t. The alternative is to unpack a tarball corresponding to an upstream release. This is really up to you and packit is able to work with both.
The key ingredient here is the config option
upstream_ref. It tells packit
the git ref which is supposed to match the archive specified in the spec file.
All commits on top of this ref are treated either as:
For downstream patches, packit creates a patch for each commit on top of
upstream_ref. Downstream packaging changes are ignored in patch files since
they can be directly committed to dist-git. You can control the ignore
mechanism with config option
Let’s have a look at source-git repo for pacemaker package:
$ git log --online bd12722 (HEAD -> c8s-test, origin/c8s-test, master) downstream packaging 7201e28 Refactor: controller: remove unused argument 91c557c Refactor: controller: convert active_op_t booleans to bitmask 2e90063 Refactor: controller: rename struct recurring_op_s to active_op_t 3ee90ce (tag: source-git-start) pacemaker-2.0.3 base
We have 5 commits:
packit.yaml has only two lines:
$ cat .packit.yaml specfile_path: SPECS/pacemaker.spec upstream_ref: source-git-start
As you can see, we are telling packit, that commit tagged as
indicates the barrier between upstream and downstream, in our case, it’s just a
single commit with the upstream archive content, but it could have been the
whole upstream git history.
So, how can one add new changes into a source-git repo? That’s simple - just commit them. If your repo is on GitHub (or another public forge), you can even force-push changes to achieve desired results with patches.
The important point with patch files is, that a commit which changes code (not downstream packaging) will be:
%setupline in the spec will be converted to
%autosetup -p1to make sure the patches are applied correctly in the
The most common workflow in the world of open source development is to accept pull requests and have merge commits in the git history. If the PRs are not rebased against master before the merge, the history may go wild. Packit is able to work with such a state by creating an ephemeral branch with linear history and generate the patch files out of it. More info.
Picking up latest upstream changes into your downstream source-git repo has multiple solutions and it’s up to you to pick the one which suits your workflow best:
git pull --rebase upstream master). This solution implies that you are able to perform the force-push operation (e.g. Fedora and CentOS dist-git instances don’t allow force-pushes). Packit will not help you with the rebase process in any way and it’s up to you to complete the rebase.
git merge upstream/master). Does not alter existing git history, yet makes it more complicated.
The format between a source-git repo and the build system is a source RPM - SRPM. We can then take the file and build it locally, send it to koji or copr and we would get the result we want - a list of binary RPMs created from the SRPM.
In the end, you can create SRPM with packit’s
$ packit srpm SRPM: /home/tt/p/c/s/pacemaker/pacemaker-2.0.3-6.gbd127227.fc32.src.rpm
These are the steps:
In this chapter, we’d cover the “sync to dist-git” part listed above. When you use source-git to track a package in Fedora, the workflow is the same as if you were in an upstream repository:
$ packit propose-update
which creates a PR similar to this: src.fedoraproject.org/rpms/python-docker/pull-request/26.