Danek Duvall wrote: > On Thu, Jun 18, 2009 at 10:36:59AM -0600, Evan Layton wrote: > >> (http://opensolaris.org/os/project/caiman/CVERS/CVERS-FUNC/) > > I think if you're going to allow the install to move forward after a > mismatch, it really needs to be opt-in, not opt-out. Don't make it easy > for the customer to screw their system up. Ultimately, I think the spec > needs a solid justification as to why the install should be allowed to > proceed after a mismatch is discovered. It sounded like you had a > developer ease-of-use argument, but I don't see that here. We had also > talked about limiting continuation to the situation where you are booted > from an older version than you're trying to install.
We want to continue the installation if at all possible since the user has asked for an installation. Most of the time this will be an automated install and the user will not be expecting to have to do interaction to complete an installation. Therefore we will continue the installation in this case and the user will be warned and the error or warning will be logged. > > It's not clear to me why this is interesting on the LiveCD. Are we talking > about a new LiveCD technology where it might be possible to install > something other than what's been booted? On live CD surrently it's not particularly interesting since it's doing an install based on a cpio of the bits booted. In this case a mismtach should never happen. However in the future it may be possible to do an IPS based intll from a live CD and we would need to make this check at that time. > > The second bullet in section 5 isn't needed any longer. > > The first bullet in section 5 doesn't make all that much sense to me. We > already talked about not having to match the timestamp portion of the > version. Also, pkg(5) already provides all the versioning info. I'm not > sure whether your requirement is already satisfied, or isn't specific > enough. Section 5 has already been updated to remove the second bullet and to add the comment that the requirement for the version string is already met by IPS. > > Also, nothing is given the version 5.11 except for the build version, which > isn't really useful at the moment. Remember, the versioning schema is: > > release,build-branch:timestamp > > and what you primarily care about are release and branch components of the > version. You should use those terms consistently. "Major release" doesn't > mean anything in the context you're using it in. The release component > isn't intended to match the version of the OS, but the version of the > software component in that package. Which may in fact have the same > version as that of the OS (how else would you version the core kernel > package, for instance), but many other packages will eventually have > independent version numbers. The branch component may not always > correspond to the build number. I should have used release instead of "Major release". I'll remove these... Shouldn't the release number for the version of the package be checked for each of these packages and won't this be expected to match? If a package has been updated within a release then only the build-branch will have changed. Since we're checking all of the packages and the release number is part of the version string why wouldn't we chekc that as part of the version checking? -evan > > Danek
