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:

  - Using "pkgadd -Z <somelist>" is equivalent to unlocking all zones
    and locking all those on <somelist>.

  - Locking a zone is equivalent to adding that zone's name to the set
    of default arguments for "-Z" on every pkgadd command and
    unlocking is equivalent to removing it from every pkgadd command

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.  For the lock
proposal, it means that the locks must be set exactly the same way
every time a given package is manipulated, and (for error checking) we
must make sure that's true.

And a pkgadd that does 'instance=overwrite' is probably special.

But, then, I'm unconvinced that the -G concept is rock solid either,
so you can adjust your view of my opinion accordingly.  ;-}

> We would still need to decide what should happen if this new option is used 
> and 
> SUNW_PKG_ALLZONES=true.  Do we obey the pkg creator or the person running 
> pkgadd?
> To be consistent with the way -G works, pkgadd should fail.

Yes, certainly.  I think that's true in both cases.

James Carlson, KISS Network                    <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
zones-discuss mailing list

Reply via email to