Hi Jean, * Jean McCormack (Jean.McCormack at Sun.COM) wrote: >>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.
Ok, fair enough. To be clear, I'm not talking about whole-sale package selection, merely selection within a given collection. > >>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. My point is that SUNWfirefox is going to be installed off the liveCD. Why would we then want to pull it from IPS because it's part of a collection as well? Are we somehow going to have logic that says "SUNWfirefox is already going to be installed because it's part of the liveCD load so don't pull it from IPS even though it's specified in the Development collection"? That seems unweildy to me. Keeping track of what's provided on the liveCD vs having to be pulled from IPS seems untenable long term imo. I suppose we could just not care about duplicate package installation (once from liveCD and then again via a collection and IPS) but I wonder if we might not run in to problems down the road. For instance, what happens if a liveCD specific customization is done to a package during image creation which is then overwritten because the package is 're-installed' from IPS as part of a collection? Somewhat hypothetical but illustrates my point. Cheers, -- Glenn
