Jean McCormack wrote: > > There are several issues with respect to the addition of software selection > in the installer that need to be addressed.
My first comment is to agree with Glynn, that I think this would be better handled as a first-boot task using Visual Panels or the packagemanager GUI itself somehow. Not only will that help keep the installer substantially simpler, but it would avoid some of the complexities that you're going to run into by trying to deal with this during install time. If you were producing a Live DVD that contained all of the software, it might make more sense, but providing functionality for network-based installs inside the installer seems like a needless duplication of functionality already provided by packagemanager or pkg(1). With that said, I've provided suggestions below based on the assumption that this is part of the installer (although again, I don't think it necessarily should be). As they might be useful in the LiveDVD scenario I mentioned. I'd also like to mention that should such a LiveDVD ever occur, folks should be aware that a snapshot of the current 2009.06 repository (for *just* the 2009.06 release + unbundleds) requires about 7.2 GiB of space with most of that gzip compressed. > 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. I see two paths: 1) Collections as group packages that were created for the convenience of users. -- Advantages: * This would work fairly well given that we already have group packages for many bits (Sun Studio, gcc, GNOME Development, netbeans, clustertools, etc.). * Allows you to avoid hard-coding summaries and descriptions of the collection, icons, etc. and place them into the package metadata. * Doesn't require coordination with whatever groups are responsible for producing the packages contained within a collection for metadata updates. * Selection of packages within a collection is fairly easy as they are just the dependencies of the group package. -- Disadvantages: * Those packages would need a generic metadata tag to make it easy to be able to identify them or a special categorisation. 2) Collections are simply packages that have been tagged with an additional, special category. -- Advantages: Selection of individual packages within a collection is easy. -- Disadvantages: Addition of an unnecessary category that will show up in package manager and other places. Higher maintenance as it requires coordination among the various groups that produce the packages contained within a collection. Whatever you do, you shouldn't be hard-coding the list of these collections. It should simply be obtained using the pkg(5) api. > 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? There's a fine line here between convenience and insanity. I do not believe that you should provide "general package installation selection" functionality from within the installer. Not only will that mean that you end up duplicating a lot of the functionality that the package manager provides, but it will just make it painful for you later on whenever bigger changes happen in the packaging system. Another issue that you're going to encounter is that pkg(5) can't tell you the space required to install a given collection ahead of time (actually it can't tell you that at all at the moment; an api change is still pending). That means that the offer of installing additional collections really can't happen until you have an installed image (that is, you've used cpio or whatever to install the 'base system image'). This is because you will have to ask ips to create an 'install plan', which you can use afterwards to determine how much space will be required and it needs an image to do that. You could possibly attempt to use the LiveCD itself as the image, but the last time I checked, the LiveCD didn't leave much free space on the ramdisk and ips may need a lot of that, or memory, to calculate some of what you asked it for. > 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. No, .p5i files would not be the way to define these :) See my response to #1. Admittedly, you could hack something up using .p5i files today, but there would be little point in doing so since that would not be much different than hard-coding the list of packages in each collection, etc. > 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. " Correct. Cheers, -- Shawn Walker
