Stephen, Thanks for answering!
On 9/12/07, Stephen Hahn <sch at sun.com> wrote: > * 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. I think it would be helpful to define exactly what you mean by an image, because I suspect that's what my question was really asking. As for filesystems, I would hope that a package technology really couldn't care less how filesystems were laid out. > > 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. I would regard those as guiding principles and find myself in general agreement. But there are other design decisions you've made (the separation from existing packaging, for example) that may be more controversial. > 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). The latter is one of my pet peeves; I'm still unsure about the former (as it essentially turns patching into upgrading) and need to see how it would work out in practice. > 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". This is one of the reasons that I asked about code availability - we can't actually take these steps unless we have access to the code to prove our case. > > 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. Why have pkg(1) separate rather than enhancing the existing tools? > We > already have code to convert existing SVR4 packages to a pkg(1) > representation (as you might guess from the 'ipkg' branded zone > example). Which implies that you've decided you need a new package format. What is that, and has that been finalized? (I know - in general terms - what sort of format I want to see, and it would be interesting to see what you've come up with.) > I know of no coherent enhanced SVR4 packaging proposal; Well, I have to say that one reason for that is the fairly widespread knowledge that there has been work being done inside Sun on a new packaging technology, so why should we invest effort in working on the existing tools? > 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. I think we're all likely to agree that the current state of patching is that it's broken. That doesn't necessarily lead to the conclusion that SVR4 packaging is broken - merely that patching is. I expect you could build a bad patch system with any packaging technology. As for zones, I have a strong belief that the current system of having the packaging system having intimate knowledge of zones and packages being split up according to zone requirements is broken. Packaging should just lay down bits; it should be up to zones (or any other user and abuser of those bits) to understand packaging, rather than having to encode increasing amounts of knowledge of other problem domains into the packaging system. > 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. That's excellent and good to hear. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
