Rainer Orth wrote: > While working with Mike Kupfer to integrate my fix for > > 6414822 don't try to build packages with closed components > > the question came up how to properly deal with a couple of packages that > cannot be built in an open build since they contain files missing from the > closed tarballs. The workaround I've come with for the CR above is to > avoid building those packages, but this is not appropriate in a couple of > cases since core packages like SUNWcsu and SUNWhea are omitted. > > My suggestion is to either move those closed components to new packages of > their own or to to really omit the affected packages when all or most files > are missing. The full list is as follows: >
[ details ellided ] > > It may seem strange to create separate *h packages that contain only a > single or just a few headers, but unfortunately those headers cannot be > included in the corresponding driver packages since those install into / > (SUNW_PKGTYPE=root), while the headers go into /usr/include > (SUNW_PKGTYPE=usr). They need to be kept separate to allow for diskless > clients and sparse-root zones. > > The question is: is the proposed creation (and granularity) of new packages > a reasonable thing to do, and are there additional issues to consider? > Mike mentioned that this splitting of existing packages into several new > ones might cause problems for upgrades, but this doesn't seem to be handled > in the currently distributed O/N sources (probably that's done in the > still-closed parts of the install/admin consolidation). > From an installation point of view, we don't currently care much - the projects need to arrive at a packaging breakdown which makes sense for them. We may choose to bring forward some recommendations or policies on package granularity based on the install strategy work I've been doing and the package/patch strategy work that's also getting under way, but what those might be is speculation at this point and I wouldn't try to impose them until they've been written down and reviewed. I don't think anything you're suggesting is unreasonable at first glance, though I wonder if some of the headers should just drop into SUNWhea rather than creating new packages for them. The movement of files from one package to another between Solaris releases is handled by the package history mechanism, which is a set of metadata that's created during the product build and placed on the Solaris media at $CDROOT/Solaris_<version>/Product/.pkghistory for the installer to consume. Suffice to say, the changes you're suggesting can be dealt with easily, as far as I can see. I don't know that this community can particularly guide you on the acceptability of specific solutions, though, as they cut across multiple technologies in the OS/Net consolidation, owners of which may or may not be represented on this list. You might do better to have this discussion on opensolaris-code instead, though we can certainly continue here if anyone has opinions or ideas to offer. Dave
