Table of Contents
On a system using Conary package management, including rBuilder, there are some key concepts you should know related to how Conary organizes software in a repository, and how it installs and manages that software on a running system. This chapter covers reading labels, versions, and flavors, and understanding their roles in Conary filesystem management.
Each component in your repository is considered unique when it has a unique combination of the following three things:
Name -- The component's name is usually derived from the package name, such as gcc:runtime.
Version string -- Each component has a complete specification that includes the label (repository location and branch of development) on which it resides, any parent labels (from which it was shadowed; see Copying and Customizing Existing Conary Packages at docs.rpath.com/conary), the package version, and the source and build increments. This specification is written out in a version string as detailed in Section 1.1.4, “Branching with Shadows and Clones”.
Flavor -- Each component can be built for one or more sets of deployment conditions. For example, it may be built differently whether its for a 32-bit system or a 64-bit system, or whether it is for a Xen virtual machine or for VMware. Each complete set of conditions is called a flavor, and each conditional within that flavor is called a flavor specification. rBuilder automates flavors through your image definitions, with each image definition corresponding to a flavor in which your packages and appliance are built. Be aware of what this looks like when you see it, and how to read each flavor specification, all covered in Section 1.2, “Flavors”.