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?
Works for me. sarah ***** > > 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? Plus wouldn't we also have > to know about changes to not only the kernel but kernel modules, > drivers etc? This is all information that while technically we could > get we would probably need to know beforehand which packages to check > which is not something we can do very feasibly. > > 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. 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. > >> >>>> I would suggest instead is to ensure that the list of package >>>> versions in >>>> the AI image is a subset of the package versions in the catalog of the >>>> repository (or repositories) you're installing from. If you're >>>> feeling >>>> exceptionally paranoid, you can check that the manifests of those >>>> packages >>>> are identical. >>> While we could do this it seams like a lot of checking that should >>> really be done by IPS for us. If IPS is not going to give us >>> something similar to what we can get from the "entire" package now >>> then we'll need IPS to give us another way to determine this >>> information. When that information is available we'll switchover to >>> using that instead of "entire" >> >> We'll likely need to give you something for the paranoid check, but the >> package version list is something you can likely do now. > > I really think we will need more than just this paranoid check part of > things as we won't know all of the packages we may need to check. That > information will have to come from IPS. > >> >>>> Otherwise, it seems like a lot of support for a condition that >>>> you're not >>>> technically supporting ... >>> I'm not sure what's meant by support here. We have to have a way of >>> determining the version and returning that information back to the >>> user. >> >> I mean support for "leaving the reservation" and installing a version of >> the OS that doesn't match what you've booted. There's no other >> reason to >> have the zfs version marked anywhere, for instance. > > 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. 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. > > -evan
