ewtroan (ewtroan) wrote,

Conary Capsules

Today is a pretty big day for us here at rPath. We've just announced support for Red Hat Enterprise Linux in our release management product offering. For the past year we've gotten significant interest from large organizations who want to use Conary's version control capabilities to manage their system deployment. Red Hat's incredible success has made their enterprise offerings a requirement for those businesses though, so they've been trying to find a way to get the best of Red Hat along with the best of rPath.

After scratching our heads for a while, we realized that what those folks want out of Conary isn't package installation, it's version control. They're looking for a way to organize sets of RPMs, define systems using versioned groups, and reliably update those systems once they're deployed. While we have previously imported operating systems (such as Novell SLES, CentOS, and Scientific Linux) we changed the packaging as part of that; doing that would (understandably) concern this set up of users who really do want RPM. But RPM does package installation, not version control, so why not marry Conary version control with RPM package installation to get the best of both worlds?

This line of thought led to capsules in Conary. They're really just a way of delegating the physical package management to another packaging system (RPM in this case) while using Conary to do the high level version orchestration. So Conary decides what gets installed, and RPM does the installation.

The packages themselves are represented as normal Conary components (rpmname:rpm), but the RPM itself gets stored in the repository instead of the contents of the individual files. When a changeset is generated, the entire RPM is sent down the wire and the conary client then passes the RPM package to RPM itself to do the install. If there are multiple RPMs they all go off to RPM simultaneously to make sure RPM can order everything properly.

What's this all mean to Red Hat Enterprise Linux users? It means that you can use Conary to define groups, rBuilder to build images, and Conary to apply updates. Strong version control, package repositories, and our deep dependency resolution are all preserved. It also means you can use RPM to query the system, install packages outside of Conary, and perform RPM system verifications. After all the installation path is identical to anaconda's, with a single RPM transaction installing the entire system for you. It's not a system that looks like Red Hat Enterprise Linux, it is Red Hat Enterprise Linux. After the system is installed the only difference is a Conary binary which can be used for package version orchestration.

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened