On 19 Nov 2013, at 9:51 pm, Daniel P. Berrange <berra...@redhat.com> wrote:
> 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=f20#n22 >> 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-patches.pl For what its worth, here is the one I use for pacemaker in rhel: https://gist.github.com/beekhof/8677396 It both helps maintain a git repo of patches and to reconcile that repo with patches in the spec file (both built patches git doesn't know about yet and patches in git that aren't being built yet). As well as asking for bugzilla numbers when updating the spec file ;-) > > > >> 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}-ow...@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 :| > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
