Working on RPMs with
quilt: an illustrated guide
it's a package for managing a series of patches. One of the things it's
really handy for is modifying source RPMs (which themselves are mostly
a series of patches on top of a base source tree, hence the good fit).
However, there's a bit of arcana involved in the process, so it's useful
to have an example.
(Since my margin is only so big, I'm going to assume that you're broadly familiar with building RPMs and RPM specfiles. If not, look around rpm.org.)
quilt setup *.spec
This creates a
liferea-1.0.9source tree as a subdirectory and sets it up for quilt.
ln -s .. patches
You only need to create this symlink if the source RPM has no patches itself; otherwise quilt does it automatically (a future version of quilt may fix this oddity). The symlink makes it so that quilt's patch area is the same as the RPM source's patch area, which is exactly what we want.
We're now ready to start actually patching things:
quilt new liferea-1.0.9-atom-title.patch
Some style issues:
- It's a good idea to start your patch series with the least controversial patches, the ones most likely to be accepted as bugfixes or whatever by the upstream developers, because the earlier they are the easier they're going to be to merge as standalone patches.
- It's a convention to name RPM patches like this. The descriptive bit in the middle shouldn't be too long, but it should give someone skimming a list of patches some idea of what your patch is about.
quilt add src/atom10.c
- edit src/atom10.c in your favorite editor
quilt refresh: this actually generates the patch file (and will happily tell you about it).
- edit the patch file to add an explanation of what the patch
is about and why it's necessary at the top; quilt will ignore
(but preserve) this text. I tend to write the sort of explanation
that I'd put in email to the upstream developers if I were to mail
the patch off to them.
cd ..to get back up to the RPM source directory
- edit the specfile to include the new patch. I usually start my own
Patch50or so, so there's a big numbering gap between upstream source RPM patches and mine.
rpmbuild -bb *.spec, and see if the patch actually works.
Now to illustrate the process of using quilt on an RPM with existing
patches, I'll delete the
liferea-1.0.9 directory and the
and start again:
quilt setup *.spec; cd liferea-1.0.9
(We don't need to set up the
patchessymlink; now that the RPM already has a patch, quilt has done this for us.)
quilt push -a
One of the few gotchas of using quilt with RPMs is that quilt defaults
to starting off a newly set up patch area with no patches applied,
instead of applying all of the patches from the RPM spec file and
starting there. So if we were to just go ahead and start a new patch,
it would wind up being at the front of the patch list, quite possibly
causing some of the other patches to fail, instead of at the end. The
quilt push -a applies all of the already existing RPM patches, so
we're where we want to be.
(I've made this mistake, and it can be very irritating.)
quilt new liferea-1.0.9-atom-times.patch
quilt add src/atom10.c src/metadata.c
- edit the two files
- edit the new patch file to explain things,
cd .., edit specfile, build, test, etc.
Interested people can find the actual patches on my liferea patches page.
PS: yes, this was sort of a cooked demo; I was less writing patches from scratch and more rolling forward existing patches I'd already written for an older version of liferea. Real quilt usage may have more flailing around with adding and removing files from patches and so on.
Sidebar: the basics of adding patches to RPM specfiles
Given a patch, like
- go the initial section of the specfile and look for the
SourceN:or a few other things), or any existing
- add a
PatchNN:line for your patch, like '
Patch50: liferea-1.0.9-atom-title.patch'. Pick an NN value that is significantly larger than any existing ones, and remember it. (Also, to keep your sanity, keep the PatchNN headers ordered.)
- skip down to the
%prepsection, which describes how to unpack the source and apply patches and what order this happens in. Add a
%patchNNdirective for your patch, after the
%setup(and any existing
%patchdirectives), like '
%patch50 -p1 -b .atomtitle'. The %patch options are more or less the same as for
- skip down to the
%changelogsection; add your own entry.
- skip up to the
Release:header and change it; for example, I add
.cks.N to most of mine. This clearly marks your RPM build as a non-standard version. (Usually my N is 1, but occasionally I have to respin an RPM and bump it up.)
- Comment out any
Vendor:lines that already exist, because you're probably not them. Optionally add your own.