Appliance Development:Package Recipe Structure

From rPath Wiki

  APPLIANCE DEVELOPMENT

A previously described, a recipe is a set of instructions that directs Conary how to build a package or group. As with recipes used to prepare food, a Conary recipe has exact ingredients that make up a perfect finished product. Also, a recipe should the follow conventions and structure recommended in rPath's documentation.

Package Recipes

Recipes can vary in length from one or two source actions to dozens of build and policy actions that should follow. The following example recipe shows myapp, a C-based program that needs to be unpacked and compiled for a package:

 
class MyApp(AutoPackageRecipe):
    name = 'myapp'
    version = '1.0'
 
    buildRequires = []
 
    def unpack(r):
        r.addArchive('http://www.example.com/foo/'
                     '%(name)s-%(version)s.tar.bz2')

The sections of a recipe serve different roles for telling Conary how to contruct the package.

Information

The first part of the recipe gives information on what the package is named, the type of code being packaged (such as source, Python, compiled Java, and RPM), and the current version of the software being packaged.

 
class MyApp(AutoPackageRecipe):
    name = 'myapp'
    version = '1.0'

AutoPackageRecipe is called a package recipe class. A package recipe class is the Python class PackageRecipe or a class which inherits from the PackageRecipe class. Conary provides several package recipe classes within its code base and in the conary.rpath.com repository, each designed to provide options specific to packaging a particular type of code. These classes are listed in rPath's documentation. Select a package recipe class appropriate for a recipe by choosing a template from Conary:Recipe Templates. In the example, the source code can be built with configure ; make ; make install, prompting the packager to use the Recipe Template for Simple C Source.

The name line should use the name of the package (or group, if this is a group), and the version should match the current version of the software being packaged. In the example, the "myapp" software is version 1.0.

Action

The next portion of the recipe indicates what actions Conary should take to assemble the package using the information provided. Actions fall into the following types:

• Source actions used to locate, obtain, and unpack software
• Build actions used to instruct Conary how to assemble and install the software
• Policy actions used to modify Conary's built-in rules for installing the software

The example has a single source action. Because of the information in the recipe, Conary is informed that myapp is a C-based program that needs to be compiled. It also is informed that the version is 1.0.

 
    buildRequires = []
 
    def unpack(r):
        r.addArchive('http://www.example.com/foo/'
                     '%(name)s-%(version)s.tar.bz2')

The buildRequires line typically lists different packages that Conary requires to install and compile the application. The package recipe class provides some build requirements, eliminating the need to explicitly specify them in the recipe. However, when you cook a package, Conary messages indicate what additional build requirements to include in the recipe.

The line def unpack(r): is a Python method definition that uses the pre-defined class variable r. Conary expects recipes to have either an unpack or a setup definition, as appropriate to the recipe template selected. The definition tells Conary what action it needs to take.

The r.addArchive line is a source action. This particular source action locates and obtains an archive as specified by the argument passed.

The argument shown includes two macros, which were previously defined as part of the package information: name and version. The macros are included using Python syntax around the macro name (percent-open-parenthesis at the beginning and close-parenthesis-s after), such as in %(name)s. Conary uses the macro definitions from the recipe information and from inherited package recipe classes to complete arguments throughout the recipe. In the example, Conary will fill in these portions of the URL to the source file for myapp which is a compressed file myapp-1.0.tar.bz2 according to the recipe.

You do not have to list common packages in buildRequires such as the gcc compiler because the AutoPackageRecipe line informs Conary that they are needed by default.