Stefano Zacchiroli wrote: > However in general it is not possible to > require that all patches apply properly to pristine source. In some > (rare fortunately) cases two patches will conflict with each other on > the pristine source and you need to make one depend on the other or the > other way round.
I recently started to use git in some of my Debian packages and thought about this issue a bit. When maintaining packages with a version control system, having each "feature" in a separate branch (branched from the upstream version) is clearly superior to a stack of patches. You retain separate history for every branch and can easily develop features independently, without having to worry about conflicts. When making a release, all the feature branches are merged to an integration branch. The end product of the packaging should be this well-integrated source, but it would be nice to also have the separate features easily extractable from the source package as well. Usually this is achieved by having the package contain a quilt patch series or similar. Converting a set of branches to a stack of patches is easy if there are no conflicts, but of course this is not always the case. A brute force method of making a patch stack which has all the feature patches applicable to pristine source and ends up with the complete integrated source would be to apply feature patch #1, revert it with the same patch reversed, apply feature patch #2, revert it, etc. and finally to apply a patch containing all the features, plus additional integration changes. The patch stack would then contain every change three times. However, conflicts between feature patches are usually small (and if they're not, maybe the features should be combined anyway), so reverting only those hunks in the previously applied patches which conflict with the new patch would not result in large reverting patches. If the patches do not conflict the revert patches would be empty. The final integration patch can be formed by diffing the upstream source with all the feature patches applied to the integration branch stored in the VCS. The end result is a patch series containing the separate feature patches, which are all guaranteed to apply to the pristine source, some small revert patches applied between them and a final patch containing real resolutions to the conflicts between the feature patches and additional integration changes. I've made a python program (actually a rather thin wrapper around git and various tools from patchutils) which makes this transformation from an upstream branch, a set of feature branches and an integration branch stored in git to a series of patch files. It's called git-genpatches and is attached to this mail. The revert patches between feature patches are made by python program minrevert (also attached) which takes patches A and B and outputs a patch reverting those hunks in patch A which overlap with hunks in patch B. Integrating git-genpatches to debian/rules is straightforward. Below are excerpts from the rules file of an unreleased package of mine. A convenience target genpatches recreates patches under debian/patches (which should be ignored by git) by applying changes in branches matching the glob 'patches/*' to a temporary branch starting from branch 'upstream' and ending with an exact copy of the integration branch called 'debian'. Directories 'contrib' and 'debian' are ignored when generating the patches: genpatches: dh_testdir -rm -rf debian/patches mkdir -p debian/patches git-genpatches -s -p debian/patches -x '*/contrib/*' -x '*/debian/*' \ -b upstream -i debian 'patches/*' Since wig and pen is not implemented in dpkg yet, there needs to be patch and unpatch targets calling quilt (or dpatch). When building in a git working tree, it is assumed that it already contains all the changes and the patches do not need to be applied: patch: stamps/patch stamps/patch: dh_testdir # Don't patch when in git tree [ -d .git ] || quilt push -a mkdir -p stamps touch $@ unpatch: dh_testdir -[ -d .git ] || quilt pop -a -rm stamps/patch The programs are still somewhat of a proof of concept quality and probably contain bugs, but I think they are useful in combining the good sides of preparing source packages with branches in version control and separating features in the final source package with a patch series. Best, Teemu
Description: Binary data
Description: Binary data
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss