Conary:Conary Repository Label Best Practices

From rPath Wiki

Conary Repository Label Best Practices

This document describes rPath’s best practices for defining Conary repository labels. A repository label is the string required to identify a software component in a conary repository. A repository label has this format:

<hostname>.<domain>@<namespace>:<product>[-]<version>[-]<stage>

The following sections provide details on each element of a Conary repository label.

Hostname and Domain

The first consideration when setting up a conary repository is the hostname that will ultimately be used to access the contents of the repository. For instance, an internal hostname is fine if the contents are only going to be used by internal developers. If the repository is going to contain software that ultimately will be used externally, then a suitable externally addressable hostname must be chosen.

For repositories which will host externally available content that is mirrored from internal development repositories, the hostname chosen must still be the external hostname. A repository map entry will be required for the internal users who need to see content before it appears on the public, external site. The repository map maps the external hostname to the internal hostname. An example:

repositoryMap updates.example.com http://rbuilder.devel.example.com/repos/updates/

Please be aware that a project name (repository name) must differ from the rBuilder hostname. See this TECHTIP for more information.

Namespace

The second consideration is picking a namespace that will be globally unique. The namespace is used to differentiate different providers of potentially the same or similar named products. A good choice for a namespace is the company name or some variation of the company name.

The namespace you choose should be also registered in the Conary namespace registry.

Product

The product element (<product>) represents the product name or project name for the software.

Version

The version element (<version>) is the major release version for the product. A major version is a version which has a dedicated maintenance stream. Note that each package in the product will have its own version, so the version in the label should represent the version of the collection of packages, or the product.

Stage

The stage element (<stage>) represents the step in the release process. Good choices for this part of the label are devel, qa, and test. Defining the label's stage element allows packages to move through a defined release process.

Dashes are not required between <product>, <version>, and <stage>; you can omit them or replace them with another suitable character.

In certain cases, it is desirable to drop the <version> or <stage> elements from the label. For example, if all of your development occurs on a single trunk, you may only have a <product>-devel label for the trunk. Likewise, it is expected that production labels will not use a <prod> element in the label, and so the label will simply have a product and version.