Thanks for the question. Yes, Conary is a packaging system that is different than .rpm or dpkg. The biggest difference with conary is that it implements build and release processes as system policies instead of developer preferences. When you build .rpms, for example, the dependency loop is closed by the developer applying his/her knowledge of the system software to the creation of an .rpm spec file. If the developer is good, you get reasonable dependency management. However, as we all know, the easiest way to close the dependency loop is to "overspecify" in the spec file. Include everything. With this approach, even if you check .rpms into a repository, you still get lots of headaches associated with managing new releases of the virtual appliance, whether associated with system software updates or application updates. This is sometimes referred to as "dependency hell."

Conary, by contrast, closes the dependency loop by inspection of components and application of policies. We take the output from your application build system, inspect it with conary, examine our policies and any that you may have inserted (i.e. no dangling symlinks), and then systematically build a release around your application. When the application changes, or when some system component changes, we systematically rebuild the virtual appliance image -- using identical policies and processes as before. As part of the build and release process, the maintenance files are created automatically. After packaging the application once, all future maintenance is free from packaging drudgery. Not so with .rpm.

Generally speaking, our approach of wrapping the system software around the application based upon the needs of the application results in an OS footprint that is one tenth the size of the smallest footprint you will achieve with the competing packaging technology. Less footprint means fewer things to break, fewer things to break into, and less maintenance work generally.

In summary, there is a learning curve with conary, but it behaves in a manner that will be familiar to any developer that has experience with source control and management systems. The cost of this learning curve is small when compared with the cost of doing effective maintenance and release management using legacy packaging technology over any significant application lifecycle period (i.e. greater than one release cycle).

Thanks again for the question, and let me know if you would like to hear more.