Once hailed as the "next-generation" of package management, Conary was
introduced by Eric Troan in 2004
at the Ottawa Linux Symposium (OLS). Though Conary hasn't replaced
traditional Linux packaging technologies, it is in wider use than one might
think. The next release promises better system management, but is anyone
actually using Conary, and where's it going? The answers are yes, and
possibly beyond Linux.
Conary was meant to solve some deficiencies that exist in standard
package formats. For instance, that package versioning as expressed by RPM
or Debian packages does not allow for branches, only a linear newer/older
model. Conary was developed to make it easier for users to create their own
distribution, from a collection of repositories. The idea being that one
might pick and choose repositories from which to install GNOME, Firefox,
etc., rather than getting all of their software from Fedora or Debian or
This has not quite come to pass, at least for most users. While there
are distributions using Conary, the primary usage of Conary these days
seems to be building custom distribution appliances for businesses.
How is Conary Different?
To learn more about Conary and its current state, we interviewed rPath's
Michael K. Johnson, founding engineer at rPath and founding technical
leader of the Fedora Project.
Despite its age, many Linux users have probably never heard of Conary or
only have heard of it in passing. Fewer still are likely to be familiar
with the details. Though Conary is lumped into discussions of package
management, it's a bit more than that. Conary is described as "distributed
software management system" for Linux distributions, as opposed to a
package management system. Rather than managing software as "specialized
archives" (as Johnson calls RPMs and Debian packages), Conary packages are
references to files in a database. The packages contain references to
components, which are divided by their roles in a package — such as
runtime requirements, documentation, libraries, etc.
Conary actually works as a sort of distributed source control
system. Software comes from specific repositories, and the associations are
much more granular than Debian packages or RPMs. For example, it's possible
to remove a file from the system and, when the package that owns the file
is updated, the individual file is not reinstalled. Files are treated as
first class objects in Conary, and can be managed individually if
Packages can have branches called shadows, a customized
version of the package that references the original plus changes, or for
minimal changes it's possible to have a "derived package" that applies
changes without rebuilding a package. As the SCM heritage suggests, Conary
also has rollback capabilities that are much more elegant than what is
allowed by RPM or dpkg.
Conary also allows for "groups," something like a metapackage or task,
that pulls together the components that make up a collection of software
meant to be installed together. GNOME or KDE might be distributed as a
group, or a collection of server software that contains all of the
libraries, applications, and supporting software that needs to be
In short, Conary introduces much more detail and flexibility in managing
Conary 2.2 is due out "soon," and Johnson says "near-final" snapshots
are already being used in Foresight Linux development. Johnson says that
2.2 introduces a new and more flexible way to manage systems:
Conary 2.2 introduces "system models", which you can think of as
"groups lite". A system model allows you to describe concisely how a
system is different from a group on which it is based. Instead of
building a group for each unique software combination, you can build
fewer base groups, and then express minor unique variations on a
per-system basis where conflict is unlikely. It makes it possible to
have a more dynamic building-block approach to configuring systems,
without giving up the control that Conary provides.
As an example, it is reasonable to have a model that expresses,
'This is one of my web application server systems, built from my
group-mywebapp manifest. It is a Dell server, so I will add to it the
Dell hardware support packages that my organization uses, which I have
bundled together in group-dell-packages. It is being deployed in my
Atlanta data center, so I need to add the administrative credentials
required for all systems deployed in my Atlanta data center, so also
include my atlanta-data-center-credentials package that sets up those
Johnson went on to give a detailed example of the process and group
definitions behind the changes that would be required to set up the server,
in just a few lines. The upshot here is that Conary 2.2 adds features that
make it very easy to clone and manage systems in a few commands.
System models are the primary new feature in 2.2, but Johnson says it
also has memory improvements and uses less bandwidth.
Conary and rPath Adoption
For all its technical advantages, Conary (like rPath) has yet to take
the world by storm. None of the major distributions have switched to Conary
as their package management system or base for development. But that
doesn't mean that it's not in use.
Conary and other package management systems are not mutually
exclusive. Johnson says there was an "epiphany," about what Conary could do
early in 2009.
We realized that we could analyze packages for
different packaging systems (e.g. RPM) and provide the same essential group
build capabilities for sets of packages (e.g. RPMs).
"encapsulating" other package formats was introduced in Conary 2.1. rPath
has been offering custom versions of CentOS, Red Hat Enterprise Linux, SUSE
Linux Enterprise, and rPath.
If you don't see much of Conary in the wild, where is it being used?
Johnson says that its largest audience is "enterprises using rPath's
product line, based on Conary, to manage diverse systems on a massive
scale," in other words "enterprise appliances." Johnson says that ISVs are
also a significant audience for Conary, and are using Conary and rPath's
tools to deliver software as software, hardware, and virtual appliances. He
cites the Department of Energy, EMC, Fujitsu, IBM, and Qualcomm as
customers who are using Conary and other rPath tools to build and manage
In general, Johnson says that there are hundreds of rPath derivatives,
but not all are public:
The derivative products we have in mind are
not like the typical 'respin.' Our derivative products will be less
visible, precisely because our products were intentionally "unflavored" so
that the derivatives wouldn't require co-branding.
Some derivatives that use Conary aren't rPath-based at all. Johnson says
many customers are using rPath supported versions of SLES, RHEL, and CentOS
to create multiple products or "system definitions" from those
Of course there's also Foresight Linux, which is based
on rPath and Conary. Foresight has had its ups and downs, and was on the ropes briefly when rPath
laid off the developers who were working on the distribution.
There's also interest in using Conary with major distributions, albeit
in a slightly different way. For instance, there's Boots,
a Conary-encapsulated mirror of Fedora. Interest in Boots started when Johnson proposed a change in
direction for Foresight Linux.
And Conary has been adopted for some derivative versions, like the Openfiler Storage Appliance.
In 2005, Johnson suggested that Conary was not limited to Linux, and
could be by the BSDs and other operating systems. So far, Johnson says that
rPath has "not received significant feedback" from customers saying it'd be
worthwhile for the company to package any of the BSDs. It's technically
possible, but not in demand.
But the company is building support for managing Windows
packages. Johnson says that the company is building in support to create
MSI installable packages for Windows, and the company specifically is hiring for
field engineers that have experience with MSI packaging and other
Windows system provisioning.
Johnson says that the company is also working on managing other package
types, so it may not be long before the rPath rBuilder tools support
creating Ubuntu or Debian based appliances as well.
Though Conary has not replaced traditional package management for most
Linux users or developers, nor has rPath become a household name for Linux
users, it's more successful than one might think at first glance. Conary
may well be worth a look for developers and ISVs that create software
appliances, or for enterprises that wish to have more control over the
management of their systems.
to post comments)