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
> 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?
zones-discuss mailing list