Ethan Quach wrote: > Evan, > > 5. (3rd bullet) - Does this really need to be stated as a > requirement on the parser? This is just a new field in the install > manifest, and the parser already has the duty to parse every > field. Seems the work here is just to define a new field > in the manifest, but then that is going to be done by this > project, not the parser project.
You right this should not have been a requirement on another project but is really more of a requirement for this project. I moved this to be a sub-bullet of the "best effort install" requirement in section 4. I also added a deliverable for this item in section 9. > > 8. Can you give a little be more high-level functional > description of what the Grub version updater and the Boot > archive updater do? > Sure, I've added what amounts to examples of what these might do. > 10. For cases 4 and 5. By definition, you've defined archive > install to be installing "a collection of bits based on the current > bits". (I assume that 'current' bits means the live running > environment). So how could archive install ever have a > mismatch? It shouldn't which is why if we find a mis-match here something has gone very wrong and we can't continue. This is why it was identified as really the only one of the use cases where we fail outright. I've added the statement to these that indicates that this should never happen. > > For case 5, is there any reason why there's not bullet to > describe image based install? No, it should have it. Thanks for catching that! > > > thanks, > -ethan > > > Evan Layton wrote: >> The functional spec for Install Versioning (version compatibility) is >> posted at: >> >> http://opensolaris.org/os/project/caiman/CVERS/CVERS-FUNC/ >> >> Your comments and feedback would be appreciated. >> >> Thanks! >> -evan >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
