On 9/30/07, Moinak Ghosh <Moinak.Ghosh at sun.com> wrote: > 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.
Was this evaluation done three years ago? I would seriously consider a reevaluation if this is the case. > 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). I assume by "how we've developed Solaris in the past" you mean a closed source, hidden development process. Regarding your comment "and how I think Sun will construct distributions in the future". Is OpenSolaris.org only a Sun marketing site? Will a community distro just be another rev of internally designed Sun Solaris w/ a misleading "open/community" label stuck on it? > > 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. Please descibe this awkwardness of handling Binary packages. > 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. Have you spoken to anyone knowledgeable at rpath about these perceived Linux couplings? Have you raised these issues with either the OpenSolaris or Conary communities? > 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.) Steve you need to take some time to explain this, as you aren't being very clear. Basically what I get is that it will be difficult to take a messy WOS/ON/BFU and write metadata about it. Well I would like to see the ration of software written to software recieved much closer than is currently the case. By having a completly seperate release engineering and distribution team, this will make it closer to an ideal distribution method. (This firewall needs to be put in place to prevent cheating and inappropriate shortcuts). "Evolving adminstration model"? please explain. > 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. > 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. Are you saying Conary is simply or IPS is simpler. From where I am sitting Conary looks simpler, and more flexible. > - 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 > > > > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/install-discuss > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/
