Mike Gerdts wrote: > On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek <[EMAIL PROTECTED]> wrote: >> Henrik Johansson wrote: >>> The easiest way would probably be to identify packages that are not to >>> be updated, in my experience packages do not differ that much between >>> local zones in production environments, but that is only based on the >>> system I have worked with. I always keep zones as similar as possible, >>> but full zones still leaves the possibility to make some changes to >>> the packages and patches in case its necessary. >> Unfortunately we have no way to know which pkgs you deliberately >> want to be different between the global and non-global zone and >> which you want to be in sync. Thats why a list where the user >> could control that would be needed. > > Isn't that the purpose of "pkgadd -G"? > > -G Add package(s) in the current zone only. > When used in the global zone, the package is > added to the global zone only and is not > propagated to any existing or yet-to-be- > created non-global zone. When used in a > non-global zone, the package(s) are added to > the non-global zone only. > > This option causes package installation to > fail if, in the pkginfo file for a package, > SUNW_PKG_ALLZONES is set to true. See > pkginfo(4). > > A package added to the global zone with "pkgadd -G" should not be > upgraded in the non-global zone.
The problem is when you look at a zone, how do you know what to sync with the global zone? For example, if you have a whole-root zone, that means you've explicitly decided you want the ability to manage pkgs in /usr, etc. independently of the global zone. With a true upgrade, those pkgs that are part of the release are upgraded anyway. What do we do with a zone migration? What pkg metadata do we have inside the zone to tell us which pkgs to sync and which not to? Jerry _______________________________________________ zones-discuss mailing list email@example.com