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 >
