Jack Schwartz wrote: > Hi Dave. > > Thanks for your comments. > > On 07/30/09 10:01, Dave Miner wrote: >> Jack Schwartz wrote: >>> Hi everyone. >>> >>> The Driver Update Use Case document has been uploaded to: >>> http://www.opensolaris.org/os/project/caiman/Driver_Update/use-case-summary.latest.txt >>> >>> >>> >>> This describes how Driver Update additions would look from a user >>> point of view, for live CD GUI, text installer, and AI. >>> >>> This has already gone through a few iterations with Frank and others, >>> and should be fairly complete, so it should be pretty solid. >>> >>> Please send comments or questions over the next couple of days, if any. >>> >> >> The solution described in use case 1 is rather un-GUI-like. I'd >> suggest discussing this with Frank, and considering more of a >> wizard-style design. Or perhaps that's what you're trying to >> describe, and the terminology just doesn't jibe. > Actually, Frank and I have already discussed this at length. We want to > build on what the DDU GUI looks like today. The "add-drivers" mode does > this. The menu selections which already exist today (install all > missing drivers, install for a specific device) can be the same buttons > which exist today. New selections can have new buttons, and text fields > can be popped up as needed for package and (repo) location entry. > > The "silent mode" will make use of a pop-up notification, and will allow > the user to enter the "add-drivers" mode. > > Was there something specific which came across as un-GUI-like?
"Looping through menus" sounds decidedly un-GUI-like to me. For this document, it might be best for you to refrain from that level of description and let the design cover it in describing the updated UI, where more precision is expected, anyway. >> >> The solution in use case 3 tries to infer format based on the >> attributes specified, and misses existing and future options. For >> example, it's possible to install SVR4 packages from an http URL, and >> IPS will have an on-disk format in the future. I strongly recommend >> making declaration of package type explicit, if that's necessary, or >> have it automatically resolved by your solution based on a recognition >> of the location's format (which may be relatively simple). > Good point. Better not to assume a certain format or location type for > different kinds of packages. I think being explicit about the type of > package is better than resolving it automatically for the following > reasons: > - It makes the package type explicit in the manifest, with no extra > effort on the user's part. (Instead of "package" elements, we can have > "IPS", "legacy" and "DU" elements to call out the specific types.) > - It is more maintainable, since if some new format of a package is > introduced, the installers won't have to be updated to recognize them. > > Additionally, it is simpler for us to implement at the outset. I would not use "package" elements. Perhaps call it a "driver_bundle" or something of the sort with an additional "type" attribute. This avoids further overloading the package term, and limits the amount of change to the schema required for additional types, should any future ones be needed. > > See sample below. >> You mention a compatibility requirement for DU packages, but I'm >> unclear how you expect to make that determination. > Packages in a DU image are nestled under a subdirectory with the version > in its name. On NV it is sol_211, for 5.11. That version is checked > when a DU image is installed. This version is how I would check > compatibility. (Reference: in onnv, check > usr/src/cmd/itutools/updatemedia.ksh and pkg2du.ksh) For our purposes here, that's potentially excessively restrictive; many S10 drivers will run just fine on Solaris next. At most I'd expect a warning from such a check. Dave
