Glossary

From rPath Wiki

This is a general glossary of popular terminology used in reference to rPath technologies.

If you find a term for which there is no definition, feel free to submit the term and its correct definition, or leave the definition blank if you are not sure.

A

Absolute Changeset

An absolute changeset is a changeset that represents the complete contents of a version of a trove, such as a package or group. This is the difference between not having the trove installed and having that version of the trove installed.

See also: relative changeset, local changeset

A changeset representing the complete contents of a version in a repository (logically, the difference between nothing at all and that version)

Appliance

A self-contained system dedicated to accomplishing a specific task or serving a specific role. An appliance is typically streamlined for efficient processing by including only those components necessary to accomplish the task. An ideal appliance requires minimal configuration or maintenance attention during its life cycle. rPath technologies provide tools to develop, deploy, and update software appliances and virtual appliances.

See also: hardware appliance.

B

Branch

A branch represents a development path for a Conary package or group. Branches can be created by cloning or shadowing, as described in Conary:Branches. The branch on which a trove resides is revealed as part of its full version string.

Branch Affinity

A concept whereby Conary will update a previously installed trove from the same branch the trove was originally installed from. Like Flavor Affinity, you can override branch affinity if you choose.

Branch Name

A branch name is a subset of a Label that contains a Namespace and a Tag. An example branch name might resemble: rpl:trunk.

Build

A build, also called an image, is an entity created from a cooked group which references all necessary troves required for a software appliance. Builds are used to create releases of your software appliance with rBuilder.

Build Count

A build count is an integer that represents how many times the source component that this component comes from has been built. This number is not provided for source components, because it is meaningless in that context. A build count is combined with an Upstream Version String and a Source Count to construct a Revision.

C

Cache

DEFINEME

Changeset

A changeset is a file that describes the differences between versions of troves (mainly components, packages, or groups). Conary uses changesets to store and update software to make more efficient use of network and storage resources. Conary changeset files have the .ccs extension.

See also: absolute changeset, relative changeset, local changeset

Clone

A clone is a copy of a trove to a different branch to create a divergent development branch. Clones of the same trove have sibling relationships, sharing the same parent branch. Reference Conary:Clones and Conary:Branches for more detailed information about clones and their role in appliance development.

See also: shadow

Component

A component is a collection of files. Conary automatically generates the components that make up a package when the package is originally created. A component is a type of trove.

See also: source component

Conary-based system

An operating system based on the Conary packaging technology, or a PC running such an operating system. A PC running rPath Linux is a Conary-based system.

Cook

A cook is Conary's way of building packages and groups. The cook process creates a changeset file based on instructions provided in a recipe.

cvc

The Conary version control program, called cvc, handles build and source management, and is responsible for all changes to the Conary repository.

D

Database

DEFINEME

Dynamic Tag

A dynamic tag is a text string which describes a file managed by Conary. By convention, a tag is a noun or noun phrase describing the file; it is not a description of what to do to the file. That is, file is-a tag. For example, a shared library is tagged as shlib instead of as ldconfig. Dynamic tags my be explicitly applied file or automatically applied based upon a Tag Description file; tagged files are processed by Tag Handlers.

E

F

Flavor

A flavor is a string of comma-separated values called flavor specifications, and each specification indicates some special condition for which a trove was built. A name, version string, and flavor together identify a unique trove 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. Flavor selection is part of cooking a group, and multi-flavor group cooks can be used to make an appliance support multiple things (such as multiple architectures). See Conary:Flavors for a more complete description and usage examples.

Flavor Affinity

A concept whereby Conary tries to pick (from the available flavors of the latest version of that trove) a trove flavor that most closely matches what you currently have installed that is compatible with your system. Like Branch Affinity, you can override flavor affinity if you choose.

Fileset

Filesets are troves that contain only files, but those files come from components in the repository. They allow custom re-arrangements of any set of files in the repository. (They have no analog at all in the classical package model.) Each fileset's name is prefixed with fileset-, and that prefix is reserved for filesets only.

Filter Expression (filterexp)

A form of regular expression used with Conary (in recipes for example). They differ from regular expressions in that $ is automatically appended when the regular expression does not end in a /, and ^ is automatically prepended if the rule starts with /. This means that (like a normal unix path) a filter expression that starts with a / character matches an absolute path. See the Conary Recipe page for more information on filter expressions.

G

Group

A group is a trove that contains other kinds of troves, typically packages or other groups. A group name starts with group-, a reserved prefix that instructs Conary to install and manage the group as a whole. 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.

Group Recipe

This kind of recipe defines a collection of troves which are usually assembled together in some kind of logicial grouping, or to provide a specific type of functionality. The core functionality in a rPath Linux derived distributions or appliances is contained in a group known as group-core, for example, and group-core.recipe is the recipe that defines that group.

H

Hardware Appliance

An appliance consisting of dedicated computing hardware for accomplishing a task. The hardware contains software or firmware to interface with users or other hardware components.

See also: software appliance, virtual appliance

I

K

L

L

Label

A label is a portion of a version string that specifies the repository host name and branch name. An example label might resemble: conary.rpath.com@rpl:trunk. See Conary:Labels for a more complete description including examples.

Label Affinity

A concept whereby Conary will update a previously installed trove from the same label the trove was originally installed from. Like Branch Affinity, you can override label affinity if you choose.

Local Changeset

A local changeset is a type of changeset that represents changes to a local machine. Conary packagers can cook a recipe in a build environment to create a local changeset and update a test system using the changeset file to test the page. This reduces the number of commits to a Conary repository prior to confirming that a package or group installs successfully.

See also: absolute changeset, relative changeset

M

Macro

Conary uses macros, either on the cvc command-line, or in Recipes to specify such information as directory path information, programs and options, and cross-compiling settings.

Merge

A merge is an operation performed by developers of a shadow to incorporate changes from a specific revision on a parent branch. Merging is not required for shadows, but the option is available for those who choose to perform the operation. Reference Conary:Shadows, Conary:Merge and Conary:Branches for more detailed information about merging.

Mirror

A mirror is a copy of a Conary repository that is updated at scheduled intervals. rPath provides rPath Appliance Platform Update Service to create and maintain mirrors for rBuilder projects.

N

Namespace

A high-level context specifier that allows branch names to be reused by independent groups. A namespace is combined with a Tag to form a Branch Name. rPath will maintain a registry of namespace identifiers to prevent conflicts. Use local for branches that will never need to be shared with other organizations.

O

P

Package

A Conary package represents an installable application on a Conary-based system. When building a package, Conary separates the package into components which represent particular parts of the package, and components can be shared as needed between packages. A package is a type of trove.

Provider-Managed Appliance

This is a type of appliance built with rPath technologies that is defined by a master group of packages. The packages are added to the master group in a manner that specifies they are all to be included in the definition of the appliance by default, and the appliance is updated by migrating to a new version of the master group. If packages are added to this type of appliance outside of being specified by default in the master group recipe, they will be removed when the appliance is migrated to a newer group version. See also User-Extensible Appliance

Q

R

Recipe

A Conary recipe is Python code that instructs Conary how to build a package or group. Conary packagers do not have to be experienced Python users to write and maintain recipes; rPath provides recipe templates and best practice information to enhance the appliance development experience.

Relative Changeset

A relative changeset is a changeset that represents the difference between two versions of a trove, such as a package or group. The changeset will change from one version to another, no matter which is older.

See also: absolute changeset, local changeset

Release

A collection of builds, each can be used to deploy a software appliance. Releases can be published or unpublished as necessary as described in rBuilder pages.

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.

Revision

A revision is a string that describes the upstream version, source count, and build count of a package or group. The revision is part of a trove's version string.

Rollback

A rollback is a set of changesets used to return the system to a previous state. Each update made on a Conary-based system creates a new rollback, and system administrators can roll back a particular number of rollbacks or to a specific rollback state. Reference Conary:Rollbacks for information and instructions about rollbacks.

S

Shadow

A shadow is a copy of a trove to a different branch to establish parallel development. Shadowing creats a parent-child relationship, evident in the trove's version string, in which the shadow can track upstream changes from the parent branch. Developers on the shadow branch can choose to merge changes from any parent revision at any time. Reference Conary:Shadows, Conary:Merge and Conary:Branches for more detailed information about shadows and their role in appliance development.

See also: clone

Software Appliance

An appliance consisting of a software stack that installs on hardware. The software includes an operating system and one or more applications that have been streamlined to a particular task. Software appliances can be licensed under a subscription license model, making them part of Software as a Service (Saas). They can be sold to customers as part of a hardware appliance solution, or they can be delivered as software which customers can install on existing hardware or as part of a virtual computing environment (see virtual appliance). A software appliance is designed like other appliances to require minimal configuration and maintenance attention.

Source Component

A source component is a component that contains the source code committed to a Conary repository and used to build 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. Also, the version string of a source component (a type of trove) does not include a build count; other components increment the build count based on a build from the source componenent.

Source Count

A source count is an integer incremented each time a version of the sources with the same upstream version string is checked in. It is similar to the release number used by traditional packaging systems. A source count is combined with an Upstream Version String and a Build Count to construct a Revision.

T

Tag

A tag is an arbitrary identifier portion of the Branch Name, and is specified by the owner of a given Namespace. In an example branch name such as rpl:trunk, the tag portion of the branch name is trunk.

Tag Description

A tag description file provides the name of a dynamic tag, a set of regular expressions that determine which files the tag applies to, and the path of the tag handler.

Tag Handler

A tag handler is an executable program or script that Conary runs to process changes involving dynamically tagged files.

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, and the term trove is used when describing Conary concepts that apply to all types of troves. A trove is identified as unique by its name, version string, and flavor.

U

Upstream Version

The upstream version of a trove is a value assigned as part of a package or group recipe for the purpose of versioning the package or group development. Appliance developers can use any value for the package or group. Conary does not increment the upstream version; Conary increments the source count and build count associated with the same upstream version. The upstream version is part of a trove's revision, a portion of the version string.

Use Flag

Modifiers which can be used to automatically enable or disable support in a source package for optional features, such as openssl, LDAP support, GNOME, KDE, IP version 6 support, Tcl/Tk, SASL, and so on. For example, the OpenLDAP clients package can be made to include SASL authentication support by specifying the use flag: openldap-clients[sasl]

User-Extensible Appliance

This is a type of appliance built with rPath technologies that is defined by multiple groups and packages. The appliance's packages are updated on a per package basis or through a complete update of all packages in all groups. Packages added to this type of appliance outside of definition in a group will be updated along with packages which are defined in the appliance's group(s). See also Provider-Managed Appliance

V

Version

A version is a trove (such as a package or group) with a particular branch and revision. The version of a trove is independent from the version of the software packaged in the trove, though the trove version can be constructed by Conary packagers to reflect the software version. Version information is revealed in a trove's version string.

Version String

A version string is a descriptive string of characters which describes the branch and revision of a trove (such as a package or group. Conary uses full and abbreviated version strings to identify a trove in its operations. The various parts of a version string are described in detail at Conary:Version String.

Virtual Appliance

A software appliance that includes necessary components to run in a virtual computing environment. rPath technologies provide tools to build a software appliance as a virtual appliance for various brands of hypervisors. The goal of virtual appliances generated in rBuilder is to require little more than a download to the appropriate virtual environment and a launch of the virtual machine.

See also: appliance

W

X

Y

Z