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.
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?
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.
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.
Danek
