Glenn, Thanks for your feedback. My responses are inline.
Jean Glenn Lagasse wrote: > Hi Jean, > > * Jean McCormack (Jean.McCormack at Sun.COM) wrote: > >> There are several issues with respect to the addition of software selection >> in the installer that need to be addressed. >> >> 1) The user interface >> >> A user should have the option to install different software collections >> (Desktop, AMP, HPC, ... etc.) >> during installation that accompany the default installation. Each >> collection should not include the 'kitchen sink' but be >> representative of a useful and popular selection of software that >> users typically use for that task. >> >> Frank has a screen shot of what he has come up with here: >> http://xdesign.sfbay.sun.com/projects/solaris/subprojects/install/design/screensSlim08-11.html >> If the number of collection choices is larger than about 6, we may have to >> add a "Software" screen following the Welcome screen. >> >> >> 2) What do we want to display in terms of data for the user with >> regard to software collections? >> >> -Do we want to display the list of packages included in a software >> collection to the users? -Do we want to provide the ability for >> users to pick and choose >> outside the collections? >> > > Providing a set of collections is fine as a first order. I'd like to > see customization of what's included in those collections. For > instance, in Frank's mockup there is a developer collection which would > seemingly include things like sunstudio, netbeans and probably gcc. > What if I don't want to install gcc though? Or I want to install gcc > 4.x instead of 3.4.3 (which is actually a choice in the current repo > contents)? Picking a collection and then allowing fine-tuning of that > collection seems useful to me (at least it has been in my experience > when using other installers that did this). In other installers I've > used, users define what 'collections' they want to install packages from > and are then given a chance to select and de-select individual packages > contained in those collections. Some packages are pre-selected while > others are not but available to be selected. Once the user has chosen > everything he wants, a dependency check is made to make sure that what > the user has chosen can be satisfied with what's been selected and if > not the additional packages required to satisfy dependencies is > displayed to the user so they can see what else is going to be > installed. > > See below. >> -Marketing requirements seem to indicate we don't need to let users >> pick individual packages(see above) >> >> Frank's response was the following which is reflected in the link >> from #1 above: >> The short answer is that I think we want to provide a short list >> (<10?) of purpose focused "collections" without listing specific >> packages, though we might provide a short description next to a >> collection that lists the major "applications" in that collection. >> I believe that the collections should contain a reasonably complete >> set of packages for that function, but selecting all collections >> would not necessarily load all packages in the repo. The package >> manager could be used to fine tune the package set after >> installation. >> > > I think we definitely need to provide some feedback about what is going > to be installed by choosing a collection. High level application names > at a minimum. Though as I've said, having a screen where the user can > fine tune the package selection of a given collection is my preferred > method. > For the first phase, we're not going to break down into package selection. If that is a desired feature, we'll do that in a subsequent phase. > >> 3) How can we maintain the list of packages now, since IPS does not >> currently provide an API for querying for the info.classification >> tag? >> >> Evan did some research on this, the summary of which follows: >> "The current Package Manager is maintaining it's own set of >> "collections" or groupings and that using the currently available >> tools we would have to do the same, using something like the .p5i >> files to define these. >> >> Going forward the IPS client API will be enhanced to allow us to use >> the info.classification tag and query IPS for this information for >> dynamically building up these collections or groupings. " >> >> >> 4) Method of installation >> >> >> I had a discussion with Sarah about our current methods of installations: >> 1) Everything is installed from media (current liveCD). Fast but not >> easily customizable. >> 2) Everything is installed from IPS repo (current AI). Customizable but >> slow. >> >> >> This project proposes to implement the following: >> 1) LiveCD contents are installed from media. >> 2) Selected package collections are available to customize the >> installation via IPS. >> >> Phase 1 of the project will install the software collections from the network >> Phase 2 of the project will allow installing the software collections from >> the IPS repo on a disk. >> > > So these approaches presume that anything contained in a collection > isn't part of the LiveCD build, right? Is that doable? > Why? Say you have a Development collection that contain SUNW firefox, SUNWmercurial and a bunch of other packages. Do we really care if the liveCD contains SUNWfirefox and the Development collection does too? It wouldn't make sense for all of Development to be in the liveCD but I don't think it's necessary to say 100% exclusion is required. Jean > Cheers, > >
