James Carlson wrote:
Jeff Victor writes:

should be added to pkgadd, e.g. "pkgadd -Z twilight" would install the pkg in all zones except zone 'twilight'. (There is probably a better option-letter.)

I think that may still end up walking into some interesting support
issues.  In fact, I don't quite see how it's fundamentally different
from Mr. Dickens' proposal, because it's possible to transform each
into the other mechanically:
...

Hmmm... My "brain-to-finger" translator was still warming up for the day. I will try again.

The point I was trying to make is that changing "zone-pkg-lock" into an option on pkgadd has these benefits:

* It's consistent with the existing model as implemented by pkgadd -G.

* Unlike zone-pkg-lock, it requires proactive thought each time it is used. This means that it is less likely to lead to unintentional problems. For example, if I change the state of a zone to "locked" and forget that I have done so, the next few pkgs I install will be omitted from that zone. That is more likely to lead to the support problems that you mentioned.

There are deeper issues lurking here.  What happens when I add a
package with one set of zones, but then try to remove it with a
different set?  I think that must fail.  For the -Z proposal, it means
that the user must somehow remember the list of zones he originally
used, or that the system must store this somewhere.

Yes, we would need to store a list of pkgs that were installed in the GZ and certain zones with one pkgadd invocation, i.e. pkgs that have a linkage between GZ and non-GZ's.

It might also be useful to query the pkg DB's with one command to learn which zones have individually installed a pkg. Of course, this would only be possible from the GZ.

Combining those two concepts would lead to the ability to query the pkg DB's and learn that the GZ's instance of a pkg is linked to the instances in a list of non-global zones, *and* that the pkg was separately installed into certain other zones.

However, it's not clear to me how much value this would bring.

--
--------------------------------------------------------------------------
Jeff VICTOR              Sun Microsystems            jeff.victor @ sun.com
OS Ambassador            Sr. Technical Specialist
Solaris 10 Zones FAQ:    http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to