2.1. Common Conary Commands

Conary requires configuration that maps its internal features to the system and network resources it's interacting with.

Table 2.1. Get Conary configuration information

conary configDisplay Conary all configuration details in the current scope.
conary config | grep installLabelPathDisplay the installLabelPath setting, which is the sequence of labels that the system will search by default when it looks for software from your current scope.

Conary can provide a lot of useful information about the software installed on the system, and the software available for installing from Conary repositories, such as a platform repository in rBuilder. To reference what some of the information means, see "Conary Versions and Flavors" chapter at docs.rpath.com/conary.

Table 2.2. Get information about installed and available software

conary queryQuery installed software for information about its components and update path.
$> conary query example
$> conary q example --info
$> conary q example --lsl
$> conary q --path /etc/example.cfg
conary repqueryQuery software available for installation from Conary repositories.
$> conary requery | more
$> conary rq example --info
$> conary rq --install-label rap.rpath.com@rpath:linux-2
conary verifyVerify whether changes have been made to installed files.

Conary requires root access to update and roll back software on the system. For updating the entire system, Conary offers two approaches: updateall and migrate.

Table 2.3. Update and roll back software and the entire system

conary updateInstall and update software from a Conary repository, including updating to an earlier version.
#> conary update example=rap.rpath.com@rpath:linux-2
#> conary update group-example
#> conary update changeset.css
conary updateallUpdate the system group and any additional components under those groups; --apply-critical installs only updates needed by Conary itself.
#> conary updateall
#> conary updateall --resolve
#> conary updateall --apply-critical
Use --items to list the items that Conary will update (without running the update):
#> conary updateall --items
conary migrateMigrate all Conary-managed components to a target version of a system group, including removing components that are not managed in the target version, and yet keeping configuration files and unmanaged files intact by default. Pass options to override some default behaviors with regards to removing unmanaged and managed files.
#> conary migrate group-toplevel-appliance
#> conary migrate group-toplevel-appliance=example.rpath.org@corp:newbranch
conary removeRemove a file from the system and from Conary management, ensuring it is not reinstalled during Conary updates of the component that originally installed it.
#> conary remove /usr/share/example/example.doc
conary eraseUninstall software packages and components
#> conary erase example
#> conary erase example:runtime
conary rollbackRoll back a system to a prior state, before one or more update commands.
#> conary rollback 1
#> conary rollback r.42
conary rblistList the update operations that would be reversed during each rollback.
#> conary rblist | more

Conary pins kernels so that you can install multiple versions of the same kernel package. Linux administrators know this is essential to ensure you have at least one functional kernel on the system, even after an update. You can unpin old kernels if you want an update operation to overwrite/remove them. You can also pin or unpin other packages or components to control whether or not the system should manage multiple versions.

Table 2.4. Pinned items allow for installing multiple versions

conary pinPin an installed component or package to prevent it from being modified or removed during a conary update or conary erase. Kernel packages are pinned by default.
#> conary pin example
#> conary pin kernel=2.6.17.11-1-0.1
conary unpinUnpin an installed component or package to allow it to be modified by a subsequent update or erase operation.
#> conary unpin example
#> conary unpin kernel=2.6.17.11-1-0.1