2006-04-21
Working on RPMs with quilt
: an illustrated guide
I've mentioned quilt
before;
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.)
First, you need to be using the sensible RPM build setup I described here. I'll also assume that you already have a source RPM that you want to modify; I'm starting with one for Liferea 1.0.9.
cd sys/RPMS/SOURCES/liferea-1.0.9
quilt setup *.spec
This creates aliferea-1.0.9
source tree as a subdirectory and sets it up for quilt.cd liferea-1.0.9
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
patches as
Patch50
or 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 series
file
and start again:
quilt setup *.spec; cd liferea-1.0.9
(We don't need to set up thepatches
symlink; 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
quilt refresh
- 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 liferea-1.0.9-atom-title.patch
:
- go the initial section of the specfile and look for the
Source:
header (orSourceN:
or a few other things), or any existingPatchNN:
lines. - 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
%prep
section, which describes how to unpack the source and apply patches and what order this happens in. Add a%patchNN
directive for your patch, after the%setup
(and any existing%patch
directives), like '%patch50 -p1 -b .atomtitle
'. The %patch options are more or less the same as forpatch(1)
. - skip down to the
%changelog
section; 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
Packager:
andVendor:
lines that already exist, because you're probably not them. Optionally add your own.
You're done.
A CSS limitation: it's not supported by lynx
That CSS isn't supported by lynx
may sound like a peculiar thing to
call a limitation of CSS, but it does have one important consequence:
If I want lynx
to format something right, I can't use CSS.
(Well, I suppose I can use CSS in addition to non-CSS methods. But I have to have the non-CSS methods.)
As strange as it may sound, I still value looking good in lynx
(and
links
, a related text mode browser). (And in Konqueror/Safari. And
even in Internet Explorer, although sometimes it's tempting. I have
pretty much given up on Netscape 4, though, except to the extent that
it's lynx
-compatible.)
One case where this comes up in WanderingThoughts is the day marker
strings (the centered bold '2006-04-20' and so on) that mark the start
of a day's posts. The morally proper way to do these is to put them
in <div class="daymarker"> and then apply the centering and bolding via
CSS. But that would look crappy in lynx
, so instead I use the older,
deprecated way:
<p class="daymarker" align=center> <b> 2006-04-20 </b> </p>
(The class is currently unused.)
These days I'm a web design pragmatist; I'm more interested in looking right than in doing something in the currently 'blessed as proper' way (especially as the currently approved way keeps changing). I prefer to do things in the proper way, because I'm geeky enough that it makes me feel good, but if the proper way conflicts with pragmatics the proper way loses. For me, intellectual purity is not worth looking ugly.