Evan Layton wrote: > 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.
I neglected to mention that I'd like to get any additional comments before noon PDT tomorrow so I can get this spec finished up... Thanks, -evan > > 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 >
