I've updated my facet/variant notes based on our discussion.
Highlights of the changes:
* L10n facets are now done in the form facet.l10n=en_US
rather than facet.l10n.en_US=true.
* facets are now ANDED together as well if the names are
different.
* facet hierarchies and wild-carding are supported.
Package facets and variants
---------------------------
Traditionally, packaging systems have placed optional components
of a package in separate packages, and established conventions
for naming such components, such as -localization-locale,
-devel -doc, etc. This method of ad-hoc decomposition
makes it more difficult for GUI programs to offer the appropriate
choices when selecting components, makes the introduction of new
optional components difficult and makes installing documentation
after the fact a painful process.
Packaging options also exist which are mutually exclusive; the typical
example is which architecture the package supports. One cannot select
both sparc and x86, since the two architecture's files intersect or
collide. Another example is debug vs non-debug binaries.
In IPS, options that may be selected or not selected, such as various
locales, documentation, etc, are referred to as facets. Options which
are mutually exclusive are called variants. Both variants and facets
appears as tags on IPS actions, and result in the action being
selected or de-selected for installation. Some examples are:
Name values
--------------------------------------------
facet.l10n zero or more of en_US, de, ...
facet.doc.man true
facet.doc true
facet.devel true
variant.arch sparc, x86, zos
variant.debug true
An action that is tagged w/ a facet or variant that is not selected
will be automatically excluded; actions w/o facets or variants are
always included. A single action may have multiple facet and variant
tags; an example would be an architecture-specific header file that's
used by developers:
file 8e7247b269fd116345abbf1aa9000a3d81ed871b
chash=1fe53e8e2d0ad25bae13e1fd622c50397a2389ce group=bin mode=0644
owner=root path=usr/include/sys/regset.h variant.arch=x86
facet.devel=true pkg.csize=4002 pkg.size=12457
This implies that facets and variants are evaluated ANDED together;
within a single facet the matched values are OR'd together. For
example, a particular action may have multiple facet.l10n tags; if
only one of those tags matches the action is selected. However, if
the facet.devel tag is also present on the action but is not set in
the image, the action is deselected.
Facets and variants are tags, and as such can initially be
set on any action, including dependencies, etc. This can make
testing problematic, however.
Facet and variants can be set to a particular value at the image or
package level. This allows just some documentation to be installed, or
just one debug driver. It also means that package developers cannot
rely on the variant to be the same for all packages; it is an error to
deliver packages that intersect when the variants are inconsistent. It
is likely also an error for an action to depend on actions in other
packages that if those actions are part of different facets than the
dependee. For example, a command should not require that other
packages be installed with the developer facet enabled if the command
doesn't also require this. This is likely to be difficult to enforce;
setting facets on packages differently that affect dependencies will
be tricky.
In order to simplify grouping of facets, wildcarding is supported
when setting image or package facets, but not variants. For example,
facet.doc.* matches facet.doc.man, facet.doc.info and facet.doc.html.
Similarly, setting facet.*=* will match all facets, installing
developer software, documentation and all available locales, and
any other optional components.
Changing either variants or facets for an installed image or package
effectively causes re-evaluation of the actions in the installed
packages, and may or may not be done live depending on the impact
of the change.
Proposed facets and variants in initial implementation:
Name Values
-----------------------------------------------------
facet.l10n en_AU.UTF-8, en_US.UTF-8, ...
facet.doc.info true
facet.doc.man true
facet.doc.html true
facet.devel true
facet.platform.sun4u true
facet.platform.sun4v true
variant.arch sparc, i386
Since previous installations have implicitly included all facets, on
upgrade the version of IPS containing facet support will likely
default to automatically including all facets, and automatically
selecting the variant that is the running machine. This will preserve
current installation features on upgrade.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
