* Peter Tribble <peter.tribble at gmail.com> [2007-09-11 15:02]: > On 9/11/07, Stephen Hahn <sch at sun.com> wrote: > I have some questions: > > 1. Is this proposal a general one, to develop an enhanced packaging > system, or a specific one, to develop your existing prototype? Initially, I would expect the project to continue the development of the existing prototype, with the aim of meeting the objectives expressed in the various posts. As that work progresses, a consensus to pursue reimplementation or rearchitecture on some scale might emerge.
> 2. It isn't entirely clear to me whether you're talking about low-level > packaging technology or a higher-level installer; please clarify. It's a low-level packager that desperately wants to be involved (or at least have a clear division of responsibility) in the management of the set of filesystems that constitute an image. For some "installers" or image manipulators, the packaging system will do much of the work; for others, the installer will instruct the packaging system where and what it should do. > 3. Clearly you've had to make some design decisions in order to get > this far - are they cast in stone or still up for discussion? If you > have made design decisions which you consider unchangeable, what are > they? (Does the invitation to participate include design and > architecture decisions, or just implementation?) Of the design points I would be hesitant to relax, the key ones are the three "no's" I mentioned and the "network first" aspect. If any of them prove truly unachievable--hi, Shawn!--then of course they will have to be modified. Other members of the project team might have other attributes they wish to preserve. For instance, Bart is very keen on getting us out of separate packaging and patching and also on refactoring the packages for minimization (although I think you'd support that, too). I suppose another way to answer this is "all aspects are debatable, as long as (a) the debate is resolved by someone ultimately writing code and (b) the end product still resembles what we were talking about at the beginning". > 4. What is the relationship of the software developed by this project to > the existing SVR4 package tools? Do you anticipate coexisting with it, > replacing it, or being subsumed by an enhanced version of it? That's a distro level decision, so I'll answer it as if I were running a distro. In my distro, pkg(1) would be the primary packaging system, with the SVR4 packaging utilities provided for compatibility. We already have code to convert existing SVR4 packages to a pkg(1) representation (as you might guess from the 'ipkg' branded zone example). I know of no coherent enhanced SVR4 packaging proposal; although I'm aware of a variety of criticisms of the SVR4 packages for image construction in various context, my most serious doubts are around the associated patch utilities' appropriateness for the typical zones deployments we're seeing. Other choices are applicable in other distro scenarios, of course. > 5. Will all the code be immediately open for the whole community > to work with? Yes. All code will be released; I am hoping we can just migrate the existing Mercurial repository (used for the prototype) to opensolaris.org. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
