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 > 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@xxxxxxxxxxxxxxxxx" > 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
