* Kyle McDonald <[EMAIL PROTECTED]> [2008-02-10 16:27]: > I've been surfing OpenSolaris.org this weekend trying to read up on a > several new project (caiman, and ips, in particular,) and I'm very > excited if a little confused. I appologize if these have been asked before. > > First, and this make make everything else fall into place, Is there a > specific definition of an 'image'? The term is a little vague. An image is a location where sets of packages can be self-consistently installed. The current plan are parent images, partial images, and user images. A standalone system has at least one parent image. All types of zones will be partial images. User images will consist of only relocatable packages (by default).
> The docs talk about how pkg creates or updates an image, but don't > really say what that is? (I'm guessing it's more than one thing hence > the vague term, but the limits on what it can and can't be are hard to > determine.) > > Is it an ISO image? Is it similiar to what I have after I copy the > Solaris DVD onto disk for my JumpStarts? A copy of all the packages I > want to make installable, but still packaged up and not directly useable? > > Or is it bootable, usable laid-out files on filesystem(s), similiar to a > BE in Live upgrade? (I'm guessing that (at least primarily) this is it?) It's closer to this case. Images can have additional context associated with them, like "prefer debug versions" or "32-bit only", via filtering. Images are also associated with one or more package repositories (by default). > But I have a few questions. I'll admit I'm no expert on SVR4 packaging, > but as I read through the pkg syntax that describe the files, > directories, permissions, dependencies, I kept thinking "What's new > here?" - granted I think the example of a syntax for drivers is new and > a better way to abstract something that was probably left to scripts in > the past. > > Am I missing something? There are more actions to come. Known needed actions include smf(5) services, user and group IDs, and some kind of post-packaging action (like the current private postrun facility). Each action can carry an arbitrary set of name-value pairs, allowing the delivery of various versions of what would otherwise be the same file. > In particular, the dependency declarations appear to (like SVR4) only > allow dependencies on specific packages? and no way to declare a > dependency on an API (or API version) without locking into a package > that provides that API? This is one of the current design arguments: we're still debating how best to declare specific-file or specific-capability dependencies. > What is the vision for handling cases like when packages from nVidia, > ATI, Intel, and Mesa all provide the OpenGL API? I imagine these are > mutually exclusive, installing at least some of their files under the > same names and in the same directories? Actually, the determination of which OpenGL objects to use is performed dynamically, in svc:/application/opengl/ogl-select:default. The end points delivered in /usr/X11/lib are symbolic links whose destinations are in /var/run/opengl, which are in turn linked by the ogl-select utility to the appropriate vendor libraries. > How does a developer package an OpenGL program, so that it knows it > needs an OpenGL library, but doesn't care which one? > > Can the package list all as optional, and specify that 'at least 1' (or > morelikely in this case 'at most 1') must be installed? We can handle optional dependencies in the "at least" sense, but OpenGL handling is probably not the case we want to use as a model--since Alan C already figured out an elegant way to handle reconfiguration. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
