On Mon, 2011-02-14 at 23:51 -0500, Richard Lowe wrote:
> As mentioned on IRC, it'd be super spiffy if you did the right thing
> with SUNW_PKG_HOLLOW/SUNW_PKG_ALLZONES,
> turning them into appropriate zone variant attributes.
Hey! You made me read pkginfo(4) ;-)
I'm not sure how well IPS maps to those parameters. Taking each in turn,
SUNW_PKG_ALLZONES
Defines whether a package, when installed, must be
installed and must be identical in all zones. Assigned
value can be true or false. The default value is false.
The setting of SUNW_PKG_ALLZONES has the effects
described below.
there's no way I can influence this in IPS yet - all I can say is that
the IPS package converted from a SVR4 package with a SUNW_PKG_ALLZONES
value of 'true' must have a nonglobal variant, and that it may have a
global variant.
The svr4convert prototype had some mogrify transforms, such as adding
prototype driver actions: we could have keyed off those, setting zone
variants, but it wouldn't have been an exact science. It's not obvious
whether just the driver actions and files that deliver kernel modules
should be non-global zone only, or whether the whole package should be
non-global zone only.
Next one:
SUNW_PKG_HOLLOW
Defines whether a package should be visible in any non-
global zone if that package is required to be installed
and be identical in all zones (for example, a package
that has SUNW_PKG_ALLZONES=true). Assigned value can be
true or false. The default value is false. The package
is not required to be installed, but if it is installed,
the setting of SUNW_PKG_HOLLOW has the effects described
below.
This is a little better - true tells me it can have the nonglobal
variant, though it's not clear whether it should have the global zone
variant (perhaps we assume it should?)
In each case though, I can't yet influence where the package should
install/appear automatically.
I think right now, having pkgsend add global/nonglobal variants would be
wrong: the packaging systems are different enough in the way they treat
zones with respect to the exact behaviour explained in pkginfo(4).
Leaving them out for now seems like the better approach - which means a
little more work for package authors at the moment. It's possible that
we could revisit this at some stage.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
