Evan Layton wrote: > 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 >
I've updated the functional spec to include these changes. Please take a look. The updated functional spec is available at the same link. (http://opensolaris.org/os/project/caiman/CVERS/CVERS-FUNC/) 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
