[install-discuss] Why aren't we using Conary?

[Moinak Ghosh]

Ken VanDine wrote:
> I have been wondering the same thing.  I haven't been able to find any problems Sun is trying to solve that haven't already been solved by conary.
>   

   Quoted below is Stephen Hahn's response to a similar question
   on pkg-discuss:

* Shawn Walker <swalker at opensolaris.org> [2007-09-29 01:01]:

> > It would be great if you could expound a bit on the zones, arch, and
> > build systems issues in respect to Conary. I think most folks know how
> > apt, rpm, and the existing system work, but Conary is the mystery for
> > me, and I'm sure others.
> > 
> > Are you able to comment specifically on any aspects of Conary that
> > didn't fit with the needs and goals of the project?
>   

  I will try.  First, let me point out that people interested in Conary
  should in fact try it out with rPath Linux, available off

  http://www.rpath.com

  (Sorry--I don't seem to be able to load a more specific page right
  now.  Presumably Google can help find a better link than I can.)

  Conary combines a number of capabilities into a single system:  the
  recipes for constructing packages are managed, as one might do with an
  SCM, by Conary, binaries are built ('cooked') by Conary--enforcing a
  number of common conventions and policies, and those binary changesets
  of served by the Conary server to Conary clients.  Conary has a rich
  versioning syntax, allowing sophisticated change management via
  branches and supports multiple repositories.  Dependencies can be
  stated or computed by the system.  

  Brian linked to an LWN article; the 2004 OLS paper is a more technical
  introduction.

  Having looked at how we've developed Solaris in the past, and how I
  think Sun will construct distributions in the future, the monolithic
  nature of Conary was problematic.  In particular, the control over the
  recipes seems like an unnecessary layering omission (to invent a term).

  As I've mentioned in the past, Sun produces a large amount of software
  via a variety of build systems, in clumps of varying sizes.  Imposing
  a uniform recipe system is possibly culturally impossible; it is
  certainly a multiyear proposition.  Asserting that a late stage in the
  process, like release engineering, be able to construct the bulk of
  this software is a strong position, and possibly not achievable.  (A
  pure OSS OpenSolaris could have less trouble, depending on what
  software it chose to exclude.)  At the time I examined Conary, its
  handling of binary packages was awkward.

  The Conary source has been, understandably, written with Linux
  distributions in mind.  Conary's policy modules are particularly
  coupled to Linux expectations and, at the time of evaluation,
  difficult to isolate.  Later versions may have fixed this aspect.

  I think a subtle but more important issue is that the approach to
  configuration management in Conary (and layered products by rPath)
  comes from having a single point of control:  assembly of the
  distribution.  The evolution I see for OpenSolaris configuration is
  somewhat different: because we have an manipulable configuration
  store, and ideas about how to realize that atop legacy configuration,
  we don't need to manipulate such metadata as a packaging operation.
  This outcome is a result of having a different balance of software
  written and software received than a typical distribution
  organization.  (That is, I see it as a strength that OpenSolaris has
  an evolving administrative model that is distinct from that of any of
  the Linux distributions.)

  Conary's impressive technology.  A Conary-based distribution of the
  OpenSolaris technologies would, I expect, be an interesting option to
  pursue.  I believe that a different set of design choices--that we're
  trying to make for image packaging--lead to similar outcomes, with
  greater flexibility and simpler operation.

  - Stephen


Regards,
Moinak.

>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> install-discuss mailing list
> install-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/install-discuss
>