On 9/13/07, Danek Duvall <danek.duvall at sun.com> wrote: > On Wed, Sep 12, 2007 at 11:12:29PM +0100, Peter Tribble wrote: > > 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 wheel comes back to my question about whether we're talking about a packager or an installer. > What disadvantages do you see in treating patching as upgrading? Upgrading means testing and requalifying all my applications. At least under Solaris, patching never has. Under the current patching scheme, it's possible to get a fix for an individual bug; upgrading the whole package involves many more changes and significantly increasing the risk to the end user. > > 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. Now, having worked with the old codebase, I can quite understand why you wouldn't want to try and build a prototype using it. That doesn't necessarily mean that you would want the final implementation to be blown up and rebuilt; that decision comes at the end rather than the beginning. http://www.joelonsoftware.com/articles/fog0000000069.html > 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. This worries me. For one, that you've already made this decision. For two, that you're going to relegate SVR4 to the sidelines. For three, that you split the tools into two and have to maintain two sets of tools going forward. > 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. We've gotta have a new format (even if we stick with the existing tools, really). I wrote up something on this; I'll see if I can find it or recreate it. > 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. I hope so too. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
