Using git for patch management in Fedora
Pádraig Brady
P at draigBrady.com
Tue Nov 19 13:45:58 UTC 2013
This is definitely worth formalizing.
On 11/19/2013 10:22 AM, Richard W.M. Jones wrote:
> Several packages are using git for patch management. eg:
>
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
> http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
All the OpenStack packages also use this technique too:
Specifically you use a comment of the form to mark the auto generated patches:
# patches_base=$tag
For example see:
http://pkgs.fedoraproject.org/cgit/openstack-nova.git/tree/openstack-nova.spec#n37
One can also add an optional +number to skip that many patches after a tag,
which we found useful in various cases.
> Some of these packages have invented home-brewed methods to generate
> the Patch lines in the spec file, eg:
>
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
https://github.com/redhat-openstack/redhat-openstack.github.com/blob/scripts/update-patches.sh
> More importantly, all are using random git repositories to store the
> exploded tree. This makes it difficult for co-maintainers and proven
> packagers to fit in with the patch management chosen by the
> maintainer. Usually they won't have access to the git repository for
> these patches, making it difficult to add patches and near impossible
> to upgrade to a new version.
>
> I think that git is an excellent way to manage patches, but we ought
> to think about formalizing this process. I think the goals should be:
>
> (1) A git repository is used that co-maintainers and proven packagers
> automatically have access to.
This would be the crux of formalizing this.
For the OpenStack packages we use a separate github organisation
to manage this (as well as other things):
http://github.com/redhat-openstack/
> (2) A single method & script is used to update the patches in the spec file.
>
> Although there is already a git repository satisfying (1) above,
> namely dist-git, it isn't suitable for storing the exploded tree since
> commits to the spec file would conflict with commits (patches) to the
> tree. So either a separate side repository which packages could
> opt-in to, or perhaps a separate branch of the same git repo could be
> used. I think using a branch would require no additional
> infrastructure.
>
> For (2) I would suggest a lightweight technique where git-managed
> patches are marked in the spec file using:
>
> ### GIT-MANAGED-PATCHES ###
> ### END-GIT-MANGED-PATCHES ###
>
> and a simple script that replaces everything between those marks with
> PatchXXXX lines. The script could be adapted from copy-patches.sh
> (see above).
>
> To apply the patches, a standard RPM macro could be created:
>
> %prep
> %setup -q
> %{git_apply_patches}
>
> which would expand to something like:
>
> git init
> git config user.email "%{name}-owner at fedoraproject.org"
> git config user.name "%{name}"
> git add .
> git commit -a -q -m "%{version} baseline"
> git am %{patches}
>
> Thoughts on this?
Using patch(1) to apply patches mostly works with a few caveats
(binary patches come to mind). Using git to apply is a new dependency
but also the most general method for applying.
thanks,
Pádraig.
More information about the devel
mailing list