Wandering Thoughts archives


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 a liferea-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 the patches 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:

  1. go the initial section of the specfile and look for the Source: header (or SourceN: or a few other things), or any existing PatchNN: lines.
  2. 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.)
  3. 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 for patch(1).
  4. skip down to the %changelog section; add your own entry.
  5. 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.)
  6. Comment out any Packager: and Vendor: lines that already exist, because you're probably not them. Optionally add your own.

You're done.

linux/PatchingRPMsWithQuilt written at 17:24:10; Add Comment

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.

web/CSSLimitationsI written at 00:53:19; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.