I have recently been working on ways to clean up the recipes in conary.rpath.com@rpl:devel. I have noticed a large amount of code duplication and forcing recipe writers to know things about how packages are built internally that they should not be required to know. Thus, I've been working to remove these hurdles to creating good packages with conary. Two recent changes include adding an RPMPackageRecipe superclass and enabling conary to automatically detect patchlevels.

RPMPackageRecipe is a superclass defined in the rpmpackage recipe in conary.rpath.com@rpl:devel. It allows individuals to easily pull *source* and patches from Fedora or RHEL RPMs. This enables removing the srpm= lines in curent rpm-based recipes. It also enables unpacking the tarball and applying designated patches with one simple command... r.unpack(). Since AutoPackageRecipe already uses r.unpack() (which is normally defined in the recipe), its possible to use both at once to create an elegant and maintainable recipe, as shown below:

loadSuperClass('rpmpackage')
class Hesiod(RPMPackageRecipe, AutoPackageRecipe):
    name = 'hesiod'
    version = '3.1.0'
    rpmRelease = '4'
    rpmPatches = [ 'hesiod-3.0.2-env.patch', ]

Thats it! The entire recipe is contained in those 6 lines. The previous version was 17 lines... quite an improvement in my view. If you have more questions as to what some of the options mean, or even what options there are, "cvc co rpmpackage=conary.rpath.com@rpl:devel" and have a look; the code is pretty simple.

If you want to use the superclass for your own recipes, add a line before your class defination saying:
loadSuperClass('rpmpackage=conary.rpath.com@rpl:devel')
Also, you will need to actually inherit from RPMPackageRecipe in your class. See above or any of the rpl:devel changes I've recently been making for examples.

A common problem with this method, though, is that the patch command for the superclass assumed the patchlevel was 1, and failed otherwise. Some Fedora patches ship with patchlevel 0, causing us a problem and making the superclass less than useful. A good example of this is grub in rpl:devel. To fix this problem, I took an idea from Gentoo Portage's econf and modified conary such that it would try to patch with patch level 1 and then try 0,2,3 (in that order) until the patch applied. If the patch did not, then instead of giving an interactive prompt like patch normally likes to do, conary now exits with an error. If, for some reason, you still need to specify the level manually, this is still supported. Note that this is in conary tip and should arrive as part of 1.0.19. These two changes cut the grub recipe from 110 lines to 44.