Conary:Flavors

From rPath Wiki

A name, version string, and flavor together identify a unique trove (such as a package or group) in a Conary repository. A single revision of a trove can be built with multiple flavors, each representing a particular scenario, such as usage on a 64-bit architecture or deployment as a VMware virtual machine.

A flavor is made up of flavor specifications, and each specification indicates some special condition for which the trove was built.

For example, one flavor specification is "vmware" which indicates that it only applies for VMware images. For appliance groups, this specification determines whether VMware tools are part of the appliance. If this specification is not explicitly included when a group is built, Conary assumes a default value of "preferred not vmware" (written "~!vmware"). If the specification is provided when building the group, Conary will built the group as "vmware" or "preferred vmware" (written "~vmware"). This specification will become part of the string that makes up the group's flavor.

Query and Read Flavors

When querying information about a trove, its associated flavor specification is a string of values separated by commas in square brackets. Use the --flavors option to reveal the flavors for a trove:

$> conary q group-core --flavors
group-core=1.1-0.14-2[~Mesa.dri,~MySQL-python.threadsafe,X,~!alternatives,~!ati, ~!bootstrap,~buildtests,desktop,~!dom0,~!domU,emacs,gcj,gnome,~!grub.static,gtk, ipv6,~!kernel.debug,~!kernel.debugdata,~!kernel.numa,~!kernel.pae,~kernel.smp, krb,ldap,nptl,~!nvidia,~!openssh.smartcard,~!openssh.static_libcrypto,pam,pcre, perl,~!pie,~!postfix.mysql,python,qt,readline,sasl,~!selinux,~sqlite.threadsafe, ssl,tcl,tcpwrappers,tk,~!xen,~xorg-server.dmx,~xorg-server.dri,
~xorg-server.xnest is: x86(i486,i586,i686,~!sse2)]

(Normally flavor specifications are presented as a single line; it has been split into multiple lines here for better readability.)

When reading a flavor, note the following mnemonics for each flavor specification:

• A flavor with no preceding mark means requires
• A flavor preceded by ~ means prefers
• A flavor preceded by ! means not required
• A flavor preceded by ~! means not preferred

More recent versions of Conary shorten these flavors to show only the specifications that are relevant to the unique trove.

Use Flavors Specifications when Building

rPath Linux (rPL) and the rPath Appliance Platform Linux Service (rLS) have components throughout with various flavor specifications. This provides packagers and appliance builders with the option to indicate a flavor specification as a way to have Conary automatically include the appropriate parts of rPL or rLS. Two common uses of this is to build for 64-bit architecture and to build for virtual environments.

For example, Example Appliance uses the appliance group "group-example." Example Appliance vendors need to provide the appliance for both 32-bit and 64-bit architectures, and for both hardware-based installs and VMware virtual machine deployments. To ensure that a the group is built for all combinations of conditions, it is built with four flavors. This results in four builds of the same version, each with a different flavor. The build command looks something like this:

$> rmake build 'group-example[is: x86]' 'group-example[vmware is: x86]' 'group-example[is: x86_64]' 'group-example[vmware is:x86_64]'

If a flavor is not specified when the package or group is build, Conary cooks the flavor that is most appropriate for the current buildFlavor (in the Conary configuration for current context).

Create Flavor Specifications when Packaging

Packagers can use conditional statements in package or group recipe to create additional flavor specifications besides those already included in Conary. These specifications are used when building the package or group to indicate which parts of the conditional should apply to the build.

An example of using this would be to build a single package with multiple configurations. Suppose the package example-package needs a configuration for marketing users and a different configuration for IT users. The recipe for example-package can use a conditional that identifies adding two specific configurations as well as adding a default configuration. The following is an example of such a recipe:

 
class ExamplePackage(PackageRecipe):
    name = 'example-package'
    version = '1.0'
    Flags.marketing = False  #default flavor is not marketing
    Flags.it = False  #default flavor is not it
 
    def setup():
       # Assert that marketing and it configurations cannot both be included
       assert not (Flags.marketing and Flags.it)
 
       # Set a macro identifying where to unpack the archive for the application
       r.macros.exampledir = '%(servicedir)s/%(name)s'
       r.addArchive('http://www.example.com/download/%(name)s_%(upver)s_install.tar.gz', 
                     dir='%(exampledir)s/')
 
       # In this example, no additional commands are required to set up the application
 
       # Include the configuration appropriate to the build flavor
        if Flags.marketing:
            r.addSource('marketing-config', dest'%(exampledir)s/config.file')
        elif Flags.it:
            r.addSource('it-config', dest'%(exampledir)s/config.file')
        else:
            r.addSource('default-config', dest'%(exampledir)s/config.file')

The following build command includes the arguments necessary to ensure example-package is built for three flavors at once, using the "prefer" and "prefer not" options with each flavor specification. Note that because these specifications are part of the example-package recipe class, they require "example-package" as part of each flavor specification:

$> rmake build 'example-package[~example-package.marketing,~!example-package.it]' 'example-package[~!example-package.marketing,~example-package.it]' 'example-package[~!example-package.marketing,~!example-package.it]'

Because the default flavor is both not marketing and not it, the third argument represents the default flavor of the group, installed when the package is installed without a flavor stated:

#> conary update example-package

When installing to use the Marketing configuration, install example-package as follows:

#> conary update example-package[example-package.marketing]

When installing to use the IT configuration, install example-package as follows:

#> conary update example-package[example-package.it]