On Tue, Nov 19, 2013 at 10:22:42AM +0000, 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=...
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
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
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.
Yep, I've done the same thing for all the packages I maintain in Fedora
and RHEL too. It makes maintaining RPMs soo much easier, particularly
when you have lots of patches to manage. The script I use is
http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patche...
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.
(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(a)fedoraproject.org"
git config user.name "%{name}"
git add .
git commit -a -q -m "%{version} baseline"
git am %{patches}
Thoughts on this?
It would certainly be nice to formalize things in this area given that
so many people are re-inventing the wheel here.
I agree that I wouldn't want to have the upstream GIT repo merged into
the Fedora dist-git repos, since that would increase their size by
many orders of magnitude.
It seems like we'd want to have a Fedora hosted parallel GIT repos for
tracking upstream GIT repos that are relevant to the Fedora RPMs.
Preferrably something that could be automated so it auto-synchronizes
the upstream branches, so Fedora maintainers just need to create a new
branch and then cherry-pick -x the patches they need.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|