Glenn Lagasse wrote: > 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. > > I see your concern. Of course we do have that problem now. If we do a live CD customization and later the person does an update, the package will get overwritten.
As for overwriting, it will only get overwritten if the IPS download is a later rev than the liveCD version. Otherwise IPS knows not to update the package, correct? Of course that could very well happen. Jean > Cheers, > >