On Mon, Jun 15, 2009 at 05:26:52PM -0600, Evan Layton wrote: > Hi Danek, > > My thoughts and responses are in-line. > > I'd like to get together on Wednesday to work through this > issue. Would 10 am PDT work for everyone?
Sure. > Thanks, > -evan > > > Danek Duvall wrote: >> On Mon, Jun 15, 2009 at 11:35:13AM -0600, Evan Layton wrote: >> >>> Danek Duvall wrote: >>>> Using the version of "entire" to detect a version mismatch isn't >>>> particularly supportable, as the package itself may disappear as we >>>> settle >>>> on a plan to get consolidations publishing pkg(5) packages natively. >>>> What >>> This is what you, Ethan and I had discussed while I was out there in >>> Menlo Park the week before last. I had thought that what you had >>> suggested was that for now we use entire but going forward we would need >>> support from IPS to give us the version similar to what we can get from >>> '"entire" today. >> >> So on further reflection I think just using the list of package versions >> as the comparison will be as good a check as any other. In some cases >> it may be overly restrictive, but in time, we hope to greatly reduce, if >> not eliminate that. > > Which packages are you referring to besides things like the zfs packages, > and maybe tings like SUNWcsr etc? Every package that's in the AI image. That way if there's *any* difference between that list of package versions and the ones you're proposing to install, you've a mismatch and can either fail or warn the user. > The appears to require us to duplicate work that IPS already does when > doing an image-update. Having to do this same kind of check is a lot of > overhead and duplicated effort that IPS could be doing for us and removes > capabilities that IPS already provides in the form of the "entire" package. I don't know how you're building the list of package versions to install; that might help me understand your point here -- pkg(5) doesn't put together a list of what's installed on the image it's running from, at least not when it's installing another image. > While you've said that is may not be available going forward something that > provides this same type of information from IPS seems to be required. This is true. And if you don't mind having to deal with the transition, then go ahead and use "entire" until it goes away. But if you can code it to > Ah ok, I see what you're getting at. The example of the zfs pool version > isn't part of the version checking per say but is part of out best effort > to do an install anyway. Right. > Even though the user is attempting to do an install the is not > "supported" we want to make a best effort to do the install anyway but > that doesn't guaranty that the install will be successful. Okay; it just seemed to me that your spec dealt mostly with that (i.e., this exceptional, unsupported case) than with the case you do plan to support. Which seemed a bit backwards to me -- why spend all your time working on the unsupported case? Danek
