>The architectural issue is this: > >The information needed to install,configure and adjust mininization >levels should be available to the tools that perform these actions, >and those tools should be installed on the system. > >Currently, the idea of clusters & metaclusters is confined to the >installer. Is the installer also going to be the way we manage software >on the machine after initial installation? > >- Bart
Hi Bart, Yes, the installer is the way we plan to manage software on the machine after initial installation. At least partly. We currently have other products like Software Update. Or Patch Pro that can also be used to manage software on the machine which have to be accounted for. The idea is that the services that Caiman provides will allow for software updates/modifications after the initial install. So, I get your point about this. I think we are in line here in our thinking. We recognize the need for capturing the data and metadata about what will be installed, managing the dependencies for what is installed, and managing the software post install. What we have today in the form of clusters and metaclusters and how that data is used and stored is not adequate for us to achieve our goals. We have tried to provide for these gaps in part by the Caiman metadata service, and its interaction with the other services pre, during and post install. What I am interested in is in what way can your proposal alleviate some of what we would have to track at install time, or pkgadd time. If we have the data about what clusters were installed, and what the dependencies were available on the system, that makes our work somewhat simpler. I was interested in more details on your ideas so that I can begin to see how this might work for us. thanks, sarah This message posted from opensolaris.org
