Glenn Lagasse wrote: ... > An installer should do the things that can't reasonably be changed > post-installation and that's it (in my opinion). An example might be > for setting ZFS compression on the root pool. While you can change the > setting post installation, it has zero effect on the data that's already > on the disk. I think any discussion about what to add to the existing > installers in terms of what they do has to start around that premise.
The above represents one of the criteria that have been applied in considering tasks available in the OpenSolaris installer. Glenn's pointed out one specific example that we haven't implemented yet, but remains under consideration. Another that's specific to interactive installers is to perform the set of tasks that "all" of the targeted users require in order to have a functioning system at the conclusion of the installation process. I say "all" because it's not truly 100%, but the threshold should be a super-majority of, say, 80%. This protects the usability of the installer for the majority by not inconveniencing them with unusual cases. Yet another criterion is whether the functionality truly requires user input, or instead can be accommodated by changes to the system's default behavior, or can be computed or inferred based on other choices. A key, but often overlooked, phrase in the above is *targeted users*. The current GUI, and live CD, is primarily targeted at desktop/laptop users who are new to OpenSolaris, because that represents a significant avenue for attracting developers. Any proposal to expand the functionality of the GUI installer should be specific and address the criteria above. Dave
