Conary: An innovative second-generation package manager

rPath’s Conary is a second-generation package manager. Considering that Erik Troan, rPath’s CTO and co-founder, was one of the original authors of the RPM package format, some might be tempted to view Conary as an effort to do things right the second time around — nor is that view far from wrong. In its design, Conary is a streamlined version of dpkg or RPM with Yum in which all the utilities of those package managers are combined in a single command and combined with version control to meet the demands of a modern distribution.

Conary relies upon a repository that is also a source control system, complete with branches and diff-like files called changesets that identify differences between the available versions of a package. Where the leading package systems identify packages only by version number, each name in a Conary repository is a unique identifier that includes such information as a package’s location in the repository, the upstream version number, the source revision, the number of the binary build, and the specific hardware architecture for which it is intended.

The advantage of these unique identifiers is that users can see the relations between files at a glance, and builds for different architectures and configurations can reside in the same repository and draw on the same files when appropriate — for documentation, for example. In addition, a later version of the program need not automatically overwrite older versions, but can coincide with them, removing a common problem with dependencies in poorly designed packages.

Preparation of packages follows the same rigid structure, but with a cooking metaphor: .recipe files are spec files that specify how sources are compiled into packages, while the command cook recipetests whether a package will build, and cvc cook packagename installs the package to a repository.

Managing software with Conary

On the local system, Conary benefits from the same orderly structure as its repositories. Basic configuration for Conary can come from three different places: /etc, the current user’s home directory, or the present working directory. By setting up configuration files differently in these places, advanced users can set up a sandbox in which to test different versions of a package, or to experiment with different repositories.

Similarly, commands for all actions involved with packages follow the same format: conary action options packagename. Most actions have both a full name and an abbreviation, creating the equivalent of GNU options and standard Unix options in a shell.

This structure gives Conary considerable versatility. For instance, the basic command to find information about available software, conary query — or conary q, if you prefer — can report on all packages, a single package, the files that comprise a package, or a package’s dependencies divided into the categories of “provides” and “requires,” depending on which options are selected. Similarly, users can query repositories with conary repquery to learn about all packages and their available revisions, the packages available for all architectures, or those available in repository branches that the local system is currently drawing on. The conary update command is especially versatile, with options to install, upgrade, or downgrade specific versions of a package, a group of packages in the repository, or all packages currently installed on the system.

Moreover, since all actions are carefully named, no experienced users are going to puzzle for very long over what such actions as conary updateall or conary rollback might do, although they might take an experiment or two to learn that all incarnations of the basic command generally need to be piped through less because of the detailed output they produce. Very little training is needed to start to use Conary, although some of the advanced features and consequences might take a while to absorb.

One especially useful action is conary pin packagename, which makes a local package unremovable until the reverse action, conary unpin packagename, is applied. Pins are especially useful for ensuring that two separate versions of a program coexist on the same system.

A particularly good use of pins is in the installation of new kernels, which is carried out using (you guessed it) conary update kernel. By default, kernels are pinned, but the online documentation suggests checking that they really are before updating, just to make sure. Once you are sure that you no longer need an earlier kernel to boot the local system, you have to unpin it before you remove it from the system.

Conary is primarily a command-line tool, but the project has also developed conary-gui, a graphical interface. Like most interfaces for package systems, conary-gui is useful for basic software installation and removal, but appears less versatile than the command-line tool — although the division of the window into Installed and Available versions is a welcome simplifying touch.

Conary’s prospects

Conary’s organization and functionality make it efficient and easy to use. However, one drawback to the system is the amount of new jargon that it introduces. I have deliberately avoided using most of it in this article, but the jargon definitely makes Conary seem more intimidating than it is.

Does Conary really need concepts like “troves,” which is described in the glossary on the project’s site as simply “a collection of files or other troves” — especially since a trove that contains other troves is essentially a package? What about a “component,” which is a type of trove that contains files for a single purpose that share a common name, such as the libraries, documentation, and binary files for a package? Or “flavor,” which is used mainly to refer to hardware architectures (although in theory it could have other meanings)? Some terms, such as “changeset,” seem both necessary and more or less self-explanatory, but what is the difference between absolute, relative, and local changesets? The use of this jargon sometimes seems irritating and self-indulgent. More importantly, it obscures the otherwise clear and comprehensive help on the project site.

So far as rPath is concerned, Conary seems less an end in itself than a tool to help build the virtual appliances that are the company’s main business. Conary is used in rPath Linux, but because rPath Linux is primarily a tool that others can use to create customized distros, the best place to see Conary action is with one of the distributions built using rPath Linux and rBuilder Online, rPath’s tool that distros can use to manage the production of their versions. Of these distributions, one of the most advanced is Foresight, which specializes in providing bleeding-edge versions of GNOME.

Conary is starting a long ways behind the .deb and .rpm package systems. Clearly, while rPath finds it useful, I suspect that Conary will be more of an inspiration than a replacement for traditional package systems in the community at large. Although almost everyone who encounters Conary is enthusiastic about it, no major distributions are apt to swap out their existing package systems in order to adopt it. However, sooner or later, as distributions become more complex and the demand for timely releases grows with the commercialization of GNU/Linux, more than one may well develop its own version of Conary’s features.

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.