Appliance Development:Conary and rPath Concepts

From rPath Wiki

  APPLIANCE DEVELOPMENT

The Conary open-source package management system is a means to package, deliver, and maintain software. Conary is at the heart of rPath's products and services. rPath Linux and Foresight Linux are built using Conary packaging technology, and rBuilder is designed for developing and distributing Conary-based appliances.

Conary was developed with features for addressing some of the common issues of Linux system administration. Conary offers the advantages of a built-in source control system to improve updating and installing software, preserving configurations during updates, and resolving dependency issues. Conary also offers a fine breakdown of system components and a structure that natively supports streamlining the operating system to support a particular application.

The following Conary concepts are described in context throughout the Appliance Development pages, but a brief definition of each is provided here as an introduction. Users should only briefly review these terms here, and then wait for their use in later context before studying them further:

Repository

A Conary repository is a network-accessible database that contains files for multiple packages, and multiple versions of these packages, on multiple development branches. Nothing can be removed from a repository after it has been added.

Trove

A Conary trove is a unit within a Conary repository or installed on a Conary-based system. A trove can be a collection of files or a container of other troves. Types of troves include components, packages, and groups. A trove is identified as unique by its name, version string, and flavor.

Package

A Conary package represents an installable application on a Conary-based system.

Component

A Conary component is a collection of files. Conary automatically generates components that make up a package when the package is originally built, and components can be shared as needed between packages.

Group

A Conary group is a trove that contains other kinds of troves, typically packages or other groups. Appliance developers often create groups of packages that should be versioned and managed together, and a "top-level" group is used to define an entire installable appliance.

Changeset

A changeset represents change from one revision of a trove to another. Conary stores installable units in a repository as changesets, and Conary messages indicate when changesets are created during build processes for packages and groups. Also, packagers can create a local changeset file to test a build prior to committing its source to a repository.

Rollback

On a Conary-based system, Conary tracks changes made during updates. Conary updates are used to install, update, and remove Conary packages and groups. Conary also tracks what changes are necessary to "undo" those updates, and it records these as rollbacks. Rollbacks can be applied with a Conary command to roll the system back to a previous state prior to one or more Conary updates.

Recipe

A Conary recipe is a set of instructions that tells Conary how to build one or more packages or groups. Recipe writing represents one of the more time-consuming parts of the packaging process, and rPath provides templates and other resources to help packagers develop recipes.

Cook

Conary's process of building a package or group from source is called cooking. The source consists of recipe files and any supplemental source files. The result of a successful cook is one or more changesets (as previously defined).

Source Component

A Conary source component contains the source code committed to a Conary repository and used to build (cook) a package or group. The same source may be used to build multiple packages or groups. A source component is managed differently from other components and it not installed with other components of a package or group.

Branch

A Conary branch is a development stream on which a trove exists. A package or group is available on a branch if it has been committed and cooked to that branch (in a Conary repository).

Label

A Conary label is used to identify troves in a repository that are in a particular development stage. Labels are used to aid in moving packages and groups through a release management process.

Shadow

A Conary shadow is a copy of package or group source from one label to another. A shadow carries information about the parent label from which it was shadowed, and modified shadows can use Conary's built-in version control to merge updates from the upstream source. Shadows are used to move development from one stage to another or to maintain a means of efficiently merging updates from upstream.

Clone

A Conary clone is a copy of a package or group source from one label to another. Unlike a shadow, a clone does not carry information about the label from which it was shadowed, and updates from an upstream source can only be applied with manual modifications to the clone. Clones are used to diverge development or to isolate one label from another.

Version String

Each Conary trove has a version string that consists of the branch on which it resides and the revision of the trove itself on that branch. Conary uses particular parts of the version string to determine information needed in various Conary operations.

Flavor

A Conary flavor is a set of conditions for which a package or group is built. A revision of a package or group can be cooked in one or more flavors corresponding to anticipated conditions of the installed environments (such as 64-bit hardware or a Xen hypervisor). Flavors are defined by conditional statements in Conary recipes and applied using flavor specifications during Conary cook operations.