Based on what was discussed at this meeting I'm making some changes to how we will determine what version checking does.
We had originally talked of using the "entire" package to start with as what we would check. However this is probably not sufficient in that packages can change underneath this without a change to "entire". For example a package listed for build 111 could but updated to 111.1 without a change to "entire". Because of this we will need to check all of the package versions for all of the packages returned from a pkg list to determine version compatibility. When checking these packages we will fail the check at the first version mismatch and report that to the user. Also discussed what the usefulness of the time-stamp check as part of the version checking. Since packages are updated based on release and branch (currently build) the time-stamp isn't very useful when checking all the packages. Because of this we will ot be using the time-stamp as part of the version check. I'm in the process of adding these changes to the function spec. Thanks, -evan Danek Duvall wrote: > 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
