On Wed, Sep 12, 2007 at 11:12:29PM +0100, Peter Tribble wrote: > 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.
It appears we need to flesh out the definition of "image". I believe that Stephen's thoughts on this run towards "an area of the filesystem where software bits are laid down along with metadata that allows us to query and manipulate the bits after initial install." I'm sure he'll correct me if I'm way off. :) > As for filesystems, I would hope that a package technology > really couldn't care less how filesystems were laid out. Individual packages themselves won't care, but likely the packaging system (or at most the image management layer immediately on top) will, in order to put things in appropriate places (filesystems might not be mounted under a common root at the time of install) and what filesystem capabilities are available, in order to take advantage of things like ZFS snapshotting. > 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. What disadvantages do you see in treating patching as upgrading? > > 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? When making large modifications to the architecture, working with an existing codebase can be incredibly limiting. We believe this is one of those "blow up and rebuild" moments. Note that as part of implementing a compatibility solution, we'll likely need to enhance the existing tools, but they won't provide the primary interface to the new system. The primary reason we've waited so long to get to the point of a formal project proposal is to get far enough down the road of creating the prototype to be sure that we weren't crazy. At least not with respect to this project. ;-) > > 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? We're hedging very strongly on defining a serialized package format. That is, the thing that corresponds to the package datastream, or the directory with reloc, root, install, pkginfo, pkgmap, etc. That's likely to be simply a repository, or an archive or a repository. As for a manifest used for creating packages, we haven't fixed that yet. At the moment we're doing most of the heavy lifting (WOS conversion) via a mini language to transmogrify the SysV packages and push them into a repo with modifications, and small tests as shell scripts that build the repository transactions one step at a time. We'll obviously need something better once other people start creating packages. > > 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? If you truly don't believe that we're capable of doing it, or think we're going about it in the wrong way and won't listen to anyone else, those are pretty good reasons. From some of the comments I've seen, it may be that people feel this way (without talking to someone in person, it can be hard to tell). Hopefully we can now start (are starting?) to dispel the issues. Danek
