As far as I know, this trick was invented by Peter Jones. Edit: Or it could be ajax?
Parted in Fedora uses a clever method to manage patches with git and “git am”.
%prep %setup -q # Create a git repo within the expanded tarball. git init git config user.email "..." git config user.name "..." git add . git commit -a -q -m "%{version} baseline." # Apply all the patches on top. git am %{patches}
The background is that there is a git repo somewhere else which stores the unpacked baseline parted tarball, plus patches (stored as commits) on top.
I assume that Peter exports the commits using git format-patch
. At build time these are applied on top of the tarball using git am
.
There are two clear advantages:
- No need to have lots of duplicate
%patch
lines in the spec file. - git-am restores permissions and empty files properly, which regular patch does not do.
With libguestfs in RHEL 6 we have roughly 80 patches, so managing these patches is very tedious, and this will greatly simplify things.
We’ve been using that in the X server for a long time, not sure if pjones got it from ajax or ajax got it from pjones.
Thanks, updated.
Mandriva’s been doing something along the same lines in its kernel package for a few years, too, using quilt:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/current/PATCHES/scripts/
I don’t really recall all the details, but it’s the same vague idea, make it simpler to manage a large patch set.
And so do some Debian developpers AFAIK.
Yes, Debian packagers also do something similar. It would be nice to push that concept further in Fedora/RedHat packaging: https://fedoraproject.org/wiki/User:Denisarnaud#Brainstorming_Section_about_Packaging (and https://fedoraproject.org/wiki/SIGs/Package_Review#Brainstorming)
I think you should add:
I don’t like having to write the purpose for every change twice. SuSE got rid of RPM changelogs.
Done
+1