Conary:conary update

From rPath Wiki

Use conary update on a Conary-based system to install, update, and downgrade software packaged for Conary. Also use the command to apply a Conary changeset file created with local recipe cooks during packaging.

Install Software

Install software as root or as a user with root access on the Conary-based system, such as a sudoer:

#> conary update example_package
$> sudo conary update example_package

Conary uses its configuration in the current scope, such as within a context, to determine the install label path for Conary updates. Conary traverses each label in the install label path in order until it finds the package, and it installs from the first label which has a package of that name. If the package does not exist on any of the labels, Conary returns an error indicating such. To prevent Conary from using the install label path to find the package, specify the label as part of the command:

#> conary update example_package=example.rpath.org

Use More of the Version String

Specify more of the version string of a package or group to target a particular branch in a repository, a specific revision of the software, or other repository targets designated by parts of the version string:

#> conary update example_package=/example.rpath.org@corp:1/1.0.15

Resolve Dependencies (--resolve)

Use the --resolve option to resolve the dependencies required for installation. The Conary-based system prompts for additional troves needed by the software that are not already installed on the system, but it offers the installer the option of reviewing this list before installing the dependent pieces.

Conary indicates dependencies with the phrase "Additional troves are needed" followed by a list of the needed troves. In the following example, the tuxpaint:runtime component of tuxpaint requires the SDL_ttf:lib component of SDL_ttf:

#> conary update tuxpaint
Additional troves are needed:
    tuxpaint:runtime=0.9.14-3-1 -> SDL_ttf:lib=2.0.7-1-1

In the next example, the installer adds --resolve to install this required trove when tuxpaint is installed:

# conary update tuxpaint --resolve
Including extra troves to resolve dependencies:
    SDL_ttf:lib=2.0.7-1-1
Applying update job 1 of 2:
    Install SDL_ttf(:lib)=2.0.7-1-1
Applying update job 2 of 2:
    Install tuxpaint(:doc :locale :runtime)=0.9.14-3-1

In the example, the output displays the installation performed to resolve the dependency in addition to the installation of the package itself.

Install Messages

While installing software, Conary displays the components installed, such as runtime, doc, and locale shown in the following example. Most lines of output are typically written on a single line, but the example shows the different messages that might appear in succession on the same line during the update:

#> conary update zile
Preparing changeset request...
Resolving dependencies...w
Requesting changeset ...
Downloading 0Kb (0%) of 102Kb at 0Kb/sec ...
Downloading 0Kb (0%) of 102Kb at 0Kb/sec ...
Resolving dependencies... 
Applying update job:
    Install zile(:data :doc :runtime)=2.2.8-1-1
Creating rollback...
Preparing update (1 of 4)...
Preparing update (2 of 4)...
Preparing update (3 of 4)...
Preparing update (4 of 4)...
Running tag prescripts...
Creating database transaction (1 of 4)...
Creating database transaction (2 of 4)...
Creating database transaction (3 of 4)...
Creating database transaction (4 of 4)...
Writing 33k of 228k (14%)...
...
Writing 228k of 228k (100%)...
Running tag post-scripts...
Committing database transaction...

The example shows the latest available version (revision) of the zile package (shown to be 2.2.8-1-1) has been installed. After the command has finished, the screen actually looks like this:

#> conary update zile
Applying update job:
    Install zile(:data :doc :runtime)=2.2.8-1-1

Upgrade or Downgrade with Update

The same update command can be used to move an installed package to a newer or an older version (revision). Following the previous example, the next example shows updating to the latest zile when a newer version of the package becomes available (shown to be 2.2.18-1-1):

#> conary update zile
Applying update job:
    Update  zile(:data :doc :runtime) (2.2.8-1-1 -> 2.2.18-1-1)

Downgrading requires specifying the earlier version (revision). Use conary query and conary repquery to compare installed revision and available revision prior to choosing a revision to update. In this example, zile is downgraded from 2.2.18-1-1 to 2.2.14-1-1:

#> conary q zile
zile=2.2.18-1-1

#> conary update zile=2.2.14-1-1
Applying update job:
    Update  zile(:data :doc :runtime) (2.2.18-1-1 -> 2.2.14-1-1)
  
#> conary q zile
zile=2.2.14-1-1

By including the desired revision of the trove in the form <trove>=<revision>, it is possible to explicitly specify the desired revision. Use this to downgrade or upgrade to the desired revision, or use it to specify which version to install for the first time (if you need another version besides the latest available).

Update by Group

A group in Conary is a trove that references other troves. This is similar in concept to how packages reference their underlying components. However, unlike packages, groups are a way to assemble sets of troves (typically packages) that are related in some way. For example, a group may be created to reference all the packages that comprise a graphical desktop environment or an entire operating system.

Also, groups reference specific versions of the underlying troves. This makes groups ideal for concisely defining a known good set of software.

Groups have versions and can be updated from one version to the next. When a group is updated, Conary verifies that all installed troves that the group references are at the version specified by the group. If any trove is not at the group-specified version, the trove is updated to that version. (Conary's label affinity, mentioned in a later section, overrides this behavior.)

While it would be possible to determine which troves were outdated, and then update them all by listing every outdated trove in one conary update<tt> command, groups make system-wide updates more efficient.

Use <tt>conary update to update a group by adding the group name to the command:

#> conary update <group>

While performing group-based updates does not equate to performing a system-wide update, Conary-based distributions typically employ a top-level group that references all troves comprising the installed distribution. For example, the top-level group for rPath Linux is group-os. Therefore, to ensure that the troves installed as part of the rPath Linux installation are all up-to-date, use the following command:

#> conary update group-os
Preparing changeset request...
Resolving dependencies...
Requesting changeset 1 of 26 ...
Downloading 1 of 26 (0%) ...
...
Downloading 1 of 26 (93%) ...
Resolving dependencies...
Requesting changeset 2 of 26 ...
Applying update job 1 of 26:
    Install libsndfile(:devel :devellib :doc :lib :octave :runtime)=1.0.11-1-0.2
Downloading 2 of 26 (0%) ...
...
Downloading 2 of 26 (70%) ...
Committing database transaction...
Requesting changeset 3 of 26 ...
Downloading 3 of 26 (0%) ...
Committing database transaction...
Requesting changeset 4 of 26 ...
Applying update job 2 of 26:
    Install libwpd(:devel :devellib :doc :lib :runtime)=0.8.3-3-0.1
...
Applying update job 26 of 26:
    Update  group-dist (0.99.0-0.1-1 -> 0.99.2-0.15-4)
Creating rollback...
Preparing update (1 of 1)...
Running tag prescripts...
Creating database transaction (1 of 1)...
Running tag post-scripts...
Committing database transaction...

Like with other conary update commands, the lines of output are overwritten on a single line. The output in the example shows the different messages that might appear in succession on the same line during such an update. However, after the command has finished, the screen would look similar to this:

#> conary update group-os

Applying update job 1 of 26:
    Install libsndfile(:devel :devellib :doc :lib :octave :runtime)=1.0.11-1-0.2
...
Applying update job 2 of 26:
    Install libwpd(:devel :devellib :doc :lib :runtime)=0.8.3-3-0.1
...
Applying update job 26 of 26:
    Update  group-dist (0.99.0-0.1-1 -> 0.99.2-0.15-4)

Conary's default configuration supports threaded updates when there are multiple changesets, the means by which Conary exchanges software between a repository and a Conary-based system. In threaded updates, one changeset is downloaded while any previously-downloaded changesets are applied. The output above shows this process: after the first changeset is completely downloaded, it is applied while the subsequent changesets are downloaded. These two operations (changeset downloading and changeset application) are displayed on one line with the download-related information appearing next to the changeset application-related information.

During a group-based update, a group's underlying troves are not checked for updates unless there is a new version of the group. This means that if a newer version of an underlying trove exists, but a newer version of the group does not exist, a group-based update would never result in the underlying trove being updated. This feature should not present a limitation because Conary-based distributions typically provide an updated top-level group each time an underlying trove is updated.

While conary update group-os ensures that all the troves installed as part of rPath Linux are updated, any additional troves installed after the rPL installation will not be updated. To ensure that both the top-level groups and the additional troves are updated, use conary updateall.

Apply Changesets

The software contained in a changeset (.ccs) is installed and can be erased or upgraded as with packages and groups from a Conary repository:

#> conary update example_package.ccs

In the following example, imagepack_update.ccs is applied which updates the imagepile package on the local system:

#> conary q imagepile
imagepack=1.0-1-1
  
#> ls /usr/share/sample_images/
sample-001.jpg
sample-002.jpg
sample-003.jpg
sample-004.jpg
  
#> conary update imagepack_update.ccs 
Applying update job:
    Update  imagepack(:data) (1.0-1-1 -> 1.1-1-1)

#> conary q imagepile
imagepack=1.1-1-1

#> ls /usr/share/sample_images/
imagepack

#> cd /usr/share/sample_images/imagepack/

#> ls
sample_101.png

Note that applying the changeset imagepack_update.ccs updated the package imagepack from version 1.0-1-1 to 1.1-1-1. During this update, the files the package had placed in /usr/share/sample_images/ were deleted, a new subdirectory called imagepack created, and a new file was added to that subdirectory. The results of applying this changeset to update the version could be the same as installing the version directly from its original repository.

Conary stores repository contents in the form of changesets. Installing a package or group from a repository is equivalent to applying a changeset representing the entire package or group as specified. This is also called an absolute changeset.

Label Affinity for Updates

The <trove>=<revision> format is actually a simplified form of Conary's basic functionality, which allows the specification of the trove's full version string. By specifying a trove's full version string, you can install software from a Conary repository even if your system has not been configured to search it.

In the following example, revision 0.9.2-1-1 of the liferea package is installed from the contrib.rpath.org@rpl:devel label:

#> conary update liferea=contrib.rpath.org@rpl:devel/0.9.2-1-1

After installing a trove with this method, subsequent updates can be done using conary update <trove>. This is a feature of Conary known as label affinity.

Label affinity refers to the condition in which after a trove is installed, Conary will continue to use the trove's label information (such as contrib.rpath.org@rpl:devel in the example) when looking for newer versions of the trove. A key advantage of this feature is that that future updates will only come from the organization that originally provided the software.

At the Conary client system installing the package, you can override label affinity by performing an update using the <trove>=<version-string> form of the conary update command. Administrators of the repository (from which you system retrieves updates) can also override label affinity using Conary's redirect capability. Such a redirect indicates to install the trove for your Conary client system from different label. (Redirect Package Policy, for repository administrators)