Hi Bart, Bart Smaalders wrote: > Dave Miner wrote: > >> Your point about boundaries is a good one. I'll just add that I >> don't regard the root-usr split as an inviolably sacred boundary; it >> was more of a convenient response to accommodate small disks >> (relative to OS size) and the diskless architecture. Neither of >> those factors are particularly prominent in my mind as we look at how >> to design the system going forward. >> >> Dave > > If we're going to relax the root/user package boundary to simply > install, can we also move any information regarding software clusters, > etc, into the packages themselves? This would yield several benefits, > including: > > 1) allow checking of cluster/package dependencies at build time. > 2) post-installation checking of effects of minimization I am not sure what this means. Can you expand on this? > > If we were to define clusters as virtual packages rather than > metadata, clusters and metaclusters could be installed via > packaging tools as well as the installer. With the addition of > the recursive dependency code into pkgadd, it would be possible > to go from a minimal install to anoher cluster with something like > > pkgadd -D -d /cdrom/.... SUNW_EndUserCluster > > or somesuch.... > > Virtual packages would have no contents, just dependencies... > but removal of packages would then alert the user that > clusters actually depend on this package.... Let me make sure I understand what you mean by virtual package... I assume that this package would have something installed on the system. So, that when we want to do the dependency checking you mention we have the metadata from this cluster package available. Is this your intent?
Your proposal, if I understand it correctly, would tie us tightly to SVR4 packaging, and going even further, to the cluster package to manage the dependencies as you describe, any additional metadata we would add to our existing packages. This means that we would have to publish the guidelines for this new packaging scheme and any additional metadata for 3rd parties to use if they want to make use of the new features. Certainly, you have seen in our architecture that we intend to have a metadata service, which will track the system configuration and installation so that users can generate profiles and replicate systems more easily than we do today. What you are suggesting might provide us some of what we need, outside or independent of the metadata service. But... there are still cases where the metadata we need would not be provided by this mechanism. For example, if users downloaded packages from a repository, we have to track the individual pkgadd's, and the location of the repository, so we can accurately reflect this in a profile. The metadata service also provides system configuration information, such as zones configuration, or Xen. I would be interested in seeing a more detailed proposal on your ideas above. thanks, sarah **** > > - Bart > > > > >
