Sarah Jelinek wrote: > Dave Miner wrote: >> Sarah Jelinek wrote: >> ... >>> >>> I was actually thinking we would run the ICT stuff before we did the >>> pkg image-update. Much like we do a pkg image-update on a live system >>> today. So, I assume ips would take care of the configuration changes >>> that are required during an image update. >>> >>> The process would be: >>> 1. Install the bits that match the current booted client. >>> 2. The normal ICT and post install stuff is run by AI. >>> 3. Then run pkg image-update if we have detected that the user asked >>> for later bits than the booted client version. >>> >>> Do you think this would work? >>> >> >> I'm sure it would work, since it's exactly the path you'd follow in >> updating from version R(unning) to version I(nstalled). But I >> question whether it's necessary... > > Our thinking was that instead of worrying about updating the installer > bits to handle the mismatch in version, and potentially introducing an > incompatibility between the installer and the kernel, we would be able > to do this to get the user the build/release they wanted in case the > booted client was an older build than the bits the user wanted to install. > > Instead of maintaining a versioning mechanism to try to decide what we > can or cannot install, we could do it this way and insure we keep things > consistent for the user. We would have to figure out if the > build/release they wanted to install is different than the build that > the client booted with. >
OK, I guess the case it covers is where a back-publish of IPS was required, and in that case I guess it's preferable than figuring out how to make the installation image able to update its own IPS and any other back-published dependencies. I guess the question that leaves is whether that's a required scenario to support. Dave
