rpmbuild-patchbuild is a simple script which synchronizes the patches in a RPM specfile and a build tree. The idea is to simplify the workflow
- Unpacking the sources.
- Apply existing patches to sources without losing history, so the patches are available for updating.
- Modify sources.
- Create new patches.
- Update patches in the spec file.
- Rebuild.
You need at least git, quilt and rpmdev-tools.
None. Just run the script, possibly after dropping it somewhere in your path.
The manpage could be viewed using nroff -man rpmdev-patchbuild.1
Ah, the manpage:
<TITLE>Manpage of RPMDEV-PATCHBUILD</TITLE> Section: User Commands (1)
Updated: Last change: $Format:%ci$
Index Return to Main Contents
rpmdev-patchbuild - synchronize patch set between spec and source
rpmdev-patchbuild [options] <command> [spec file]
rpmdev-patchbuild is designed to support the workflow when maintaining patches in RPM spec files. It can export existing patches to a build tree. This build tree can be modified with new or updated patches. Eventually, the patches in the spec file can be updated (i. e., replaced) with the patches in the build tree.
The command argument is one of
-
- export
- Retrieves the sources as defined in the spec file and unpacks them into a build tree. The patches in the spec are applied as a patch series in this tree.
- import
- Import the patches from the build tree. The patches in the spec file are replaced with the patches from build tree.
- status
- Display the patch status. A patch can be deleted, new, modified or unchanged. A new patch might conflict if using a numeric prefix used by another patch
- reset
- Reset the patch numbering (git mode only). Removes existing patches and replaces them with a new set generated by git format-patch.
- version
- Print version
- spec file
-
The spec file to use. Defaults to *.spec (which must match a single
file to work).
- -m ,--mode [git|quilt|autosetup]
- Work either in git, quilt or autosetup mode. See QUILT MODE, GIT MODE, and AUTOSETUP MODE. Modes can be abridged to the initial letters g, q and a.
- -o,--options
- Options used with %patch when importing new patches. Defaults to -p1. Existing %patch invocations are used as-is.
- -w,--working-dir
- Build directory where sources are unpacked. Defaults to patchbuild.
- -h,--help
- Display usage summary.
- -v,--version
-
Display version.
In quilt mode the build tree is initiated with a quilt(1) patchset. This mode can always be used for "normal" spec files using %patch to apply the patches. It does not parse or generate any patch metadata. It also leaves patch naming including numbering to the user. After a quilt refresh command the patchset is updated and visible for rpmdev-patchbuild. Quilt mode is used by default if at least one patch is deemed as non-git.
In git mode the build tree is initiated with a git(1) repository, and each patch in the spec will be applied using git am. Requires that all spec patches are git-formatted. This mode is used by default if all patches in the spec are deemed as git patches according to some heuristics.
rpmdev-patchbuild does not import the git repo directly, it
uses the patchbuild/patches directory. One way to feed it
is to just invoke something like git format-patch --start-number 7
-o ../patches HEAD^..HEAD. This gives user fine-grained control over
the patches imported. The alternative is to use the reset command
which generates a fresh, re-numbered patchset in ../patches.
In git mode all changes done by %prep besides the actual patching is discarded by export.
In the autosetup mode rpmdev-patchbuild assumes that the spec file doesn't use %patch macros for applying the patches. No modifications are done to the %prep section in the spec file, only the Patch: tag lines are parsed and modified. Likewise, no modifications are done to the spec when it is used to unpack the sources in the export command.
Like in the git mode, only the patches/ directory is consulted for the actual patchset. This means that rpmdev-patchbuild is agnostic as to how this is created. A common way would be the git format-patch described for the git mode.
Updating an existing patch does not affect the spec file, only the contents of the patch file.
When deleting a patch the corresponding entry in the spec is commented out.
When inserting a new patch, the Patch: tag line and the %patch is inserted ordered to existing lines. If there is no existing patch the tag line is inserted after the last Source: and the patch line after %setup.
Both deleted and inserted patches creates fixes which looks ugly and needs some manual editing before committing.
When imported a new patch must be designated a number. If the patch filename doesnt have a numeric prefix the next available number is used. It the patch has a numeric prefix it will be used unless it's already used in the spec. In this case there is a warning and next available number is used.
A session using rpmdev-patchbuild might look like:
$ fedpkg clone foo
$ cd foo
$ rpmdev-patchbuild export
$ cd patchbuild/foo-1.0.3
< patch the code and update patches>
$ cd ../..
$ rpmdev-patchbuild status
$ rpmdev-patchbuild import
$ rpmbuild -D "_sourcedir $PWD" -ba *.spec
< patch broken... fix in patchbuild/foo-1.0.3>
$ rpmdev-patchbuild import
$ rpmbuild -D "_sourcedir $PWD" -ba *.spec
<all OK, commit changes in main git repo>
$ git commit -am "foo fixed with new patches"
When unpacking the build dependencies are not used. In corner cases where the %prep section uses tools from the builddeps the export command will fail. Installing the build dependencies for the spec file should fix it.
If a specfile unpacks two or more separate directories in the top level rpmdev-patchbuild gets confused.
quilt(1)
git(1)
- NAME
- SYNOPSIS
- DESCRIPTION
- ARGUMENTS
- OPTIONS
- QUILT MODE
- GIT MODE
- AUTOSETUP MODE
- SPEC FILE MODIFICATIONS
- EXAMPLES
- BUGS
- SEE ALSO
This document was created by man2html, using the manual pages.
Time: 13:56:07 GMT, October 23, 2015