On Thu, Nov 06, 2008 at 10:20:43AM -0500, Dr. Hung-Sheng Tsao (LaoTsao) wrote:
> anyone know when the brandz for s10 will be out?
> e.g. running s10 with opensolaris zone?
No target has been set for this. We cannot reasonably manage such a
project until s10 begins taking less change. The current understanding is
the need for such a feature will co-incide with the release of an
enterprise version of opensolaris, or an early update (6 months?) to an
enterprise opensolaris-based release.
> Jerry Jelinek wrote:
> >Mike Gerdts wrote:
> >>On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek <[EMAIL PROTECTED]>
> >>>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?
> >zones-discuss mailing list
> zones-discuss mailing list
zones-discuss mailing list