swpackage(4)swpackage(4)NAMEswpackage - product specification file (PSF) format
DESCRIPTION
Introduction
The command packages software into:
· a distribution directory (which can be accessed directly or
copied onto a CD-ROM),
· a distribution tape, such as DDS, nine-track or cartridge
tapes.
Both directory and tape distributions use the same format. SD can read
both and tape depots. See sd(4) for details on tape format.
The software is organized into a four-level hierarchy of software
objects: and Bundles and subproducts are recursive: a bundle can con‐
tain other bundles, and a subproduct can contain other subproducts.
The files that make up a software package are contained in filesets.
Filesets are contained in subproducts and/or products. Currently, HP
does not support customer creation of software bundles to contain the
entire application. The attribute tables that follow show the
attributes of each level of the software packaging hierarchy.
A (PSF) defines how a product is structured and the attributes that
apply to it. This manual page describes the syntax and semantics of a
PSF.
Layout Version
SD object and attribute syntax conforms to the specification of the
standard. The previous SD layout_version 0.8 is also supported. SD
for HP-UX version 10.10 and later can read or write either layout ver‐
sion. SD commands still accept the keyword names associated with the
older layout version, but you should use layout_version 0.8 only to
create distributions readable by older versions of SD.
What layout_version the SD commands write is controlled by the option
for and
The version used by can be also controlled by specifying the lay‐
out_version attribute in the PSF. However, if the layout_version
attribute in the PSF is 1.0, the is_locatable attribute defaults to
true in all cases, and must be explicitly set to false.
For a full description of the command, see the swpackage(1M) manual
page.
Layout version 1.0 adds significant functionality not recognized by
systems supporting only 0.8, including:
· Category class objects (formerly the attributes within the
bundle or product class).
· Patch-handling attributes, including
· The fileset attribute, which permits you to specify the
architecture of the target system on which the product will
run.
In addition to adding new attributes and objects, layout_version 1.0
changes the following preexisting 0.8 objects and attributes as fol‐
lows:
· Replaces the depot with the object with a attribute.
· Replaces the definition within products and bundles with a
attribute and a corresponding object defined outside the
product or bundle.
· Pluralizes the and fileset attributes (to and
· Changes the attribute to
PRODUCT SPECIFICATION FILE SYNTAX
A PSF is structured as follows:
[<distribution specification>]
[<vendor specification>]
[<category specification>]
[<bundle specification>]
...
<product specification>
[<control script specifications>]
[<subproduct specifications>]
<fileset specification>
[<control script specifications>]
<file specifications>
[<fileset specification>]
...
[<vendor specification>]
[<product specification>]
...
In summary, the user can:
· Specify one or more products.
· For each product, specify one or more filesets.
· For each fileset, specify one or more files.
· (optional) Specify attributes for the target depot or tape.
· (optional) Specify one or more bundles, defining the bundle
contents.
· (optional) Specify vendor information to be used with subse‐
quent products and bundles.
· (optional) For each product, specify one or more subproducts,
defining the subproduct contents.
· (optional) For each product or fileset, specify one or more
control scripts.
Each software object has user-defined attributes. Most attributes are
optional. All objects and attributes are defined using a
syntax. The is an identifier for the attribute.
Some attributes allow multiple values. You can specify values with a
keyword/list syntax:
You can also use a list following the keyword:
value1
value2
value3
...
Specific rules for each keyword are:
· All keywords require one or more values, except as noted. If
the value is missing an error is given.
· Comments must be preceded by A comment can appear on a line
by itself or following the keyword-value syntax within the
PSF.
· Use double quotes (") to define values that span multiple
lines:
· Double quotes (") are
optional when defining a
value that contains embed‐
ded whitespace.
Attribute Table
The following tables summarize the
objects and attributes which can be
defined in a PSF. These objects and
attributes can appear in any order
when defining a distribution, vendor,
category, product, or bundle, except
that the layout_version attribute
must be first. Each object and
attribute is identified by a keyword.
Object keywords do not have associ‐
ated values. Attribute keywords have
one or more values.
· Attributes marked with a
determine the uniqueness of
a product, bundle, or file‐
set. Their values may also
be of the type when used in
a version component of a
software specification.
· can be defined within prod‐
ucts or filesets or both.
· You can define your own
attributes. See for more
information.
┌──────────────────┬─────────────────────┬─────────┬───────────────────────┐
│Keyword │ Type │ Size │ Example │
├──────────────────┼─────────────────────┼─────────┼───────────────────────┤
│distribution │ │ │ │
│ layout_version │ revision_string │ 64 │ 1.0 │
│ tag │ tag_string │ 64 │ EXAMPLE_DEPOT │
│ copyright │ multi_line_string │ 8192 │ < data/copyr.depot │
│ description │ multi_line_string │ 8192 │ < data/descr.depot │
│ number │ one_line_string │ 64 │ B2358-13601 │
│ title │ one_line_string │ 256 │ Example packages │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼───────────────────────┤
│vendor │ │ │ │
│ tag │ tag_string │ 64 │ HP │
│ description │ multi_line_string │ 8192 │ < data/descr.hp │
│ title │ one_line_string │ 256 │ Hewlett-Packard Co. │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼───────────────────────┤
│category │ │ │ │
│ tag │ tag_string │ 64 │ patch_normal │
│ description │ multi_line_string │ 8192 │ For normal problems │
│ revision │ revision_string │ 64 │ 0.0 │
│ title │ one_line_string │ 256 │ Category of Patches │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼───────────────────────┤
│bundle │ │ │ │
│* tag │ tag_string │ 64 │ SD │
│* architecture │ one_line_string │ 64 │ HP-UX_B.11.11_32/64 │
│ │ │ │ HP-UX_B.11.23_IA/PA │
│ category_tag │ one_line_string │ 64 │ OrderedApps │
│ contents │ repeatable list │ 8192 │ pr.fs.r=1.0,a=,v= │
│ copyright │ multi_line_string │ 8192 │ <data/copyr.sd │
│ description │ multi_line_string │ 8192 │ <data/descr.sd │
│ layout_version │ revision_string │ 64 │ 1.0 │
│ machine_type │ uname_string │ 64 │ 9000/[78]?? │
│ │ │ │ ia64* │
│ number │ one_line_string │ 64 │ B2001A │
│ os_name │ uname_string │ 64 │ HP-UX │
│ os_release │ uname_string │ 64 │ ?.11.* │
│ os_version │ uname_string │ 64 │ * │
│ revision │ revision_string │ 64 │ A.01.00 │
│ title │ one_line_string │ 256 │ Software Distributor │
│ vendor_tag │ tag_string │ 64 │ HP │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼───────────────────────┤
└──────────────────┴─────────────────────┴─────────┴───────────────────────┘
Attribute Table (continued)
┌──────────────────┬─────────────────────┬─────────┬────────────────────────┐
│Keyword │ Type │ Size │ Example │
├──────────────────┼─────────────────────┼─────────┼────────────────────────┤
│product │ │ │ │
│* tag │ tag_string │ 64 │ SD │
│* architecture │ one_line_string │ 64 │ HP-UX_B.11.11_32/64 │
│ │ │ │ HP-UX_B.11.23_IA/PA │
│ category_tag │ one_line_string │ 64 │ OrderedApps │
│ contents │ repeatable list │ 8192 │ pr.fs.r=1.0,a=,v= │
│ copyright │ multi_line_string │ 8192 │ <data/copyr.sd │
│ description │ multi_line_string │ 8192 │ <data/descr.sd │
│ directory │ path_string │ 1024 │ / │
│ is_locatable │ boolean │ 9 │ false │
│ is_patch │ boolean │ 9 │ false │
│ layout_version │ revision_string │ 64 │ 1.0 │
│ machine_type │ uname_string │ 64 │ 9000/[78]?? │
│ │ │ │ ia64* │
│ number │ one_line_string │ 64 │ B2001A │
│ os_name │ uname_string │ 64 │ HP-UX │
│ os_release │ uname_string │ 64 │ ?.11.* │
│ os_version │ uname_string │ 64 │ * │
│ postkernel │ path_string │ 255 │ /usr/bin/kernel_build │
│ readme │ multi_line_string │ 1024 │ <data/README.sd │
│ revision │ revision_string │ 64 │ A.01.00 │
│ title │ one_line_string │ 256 │ Software Distributor │
│* vendor_tag │ tag_string │ 64 │ HP │
│ control_files │ │ │ │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼────────────────────────┤
│subproduct │ │ │ │
│ tag │ tag_string │ 64 │ Manager │
│ contents │ one-line list of │ │ commands agent data │
│ │ tag_string values │ │ data man │
│ description │ multi_line_string │ 8192 │ < data/desc.mgr │
│ title │ one_line_string │ 256 │ Management Utilities │
│end │ │ │ │
├──────────────────┼─────────────────────┼─────────┼────────────────────────┤
└──────────────────┴─────────────────────┴─────────┴────────────────────────┘
Attribute Table (continued)
┌─────────────────┬──────────────────────┬─────────┬─────────────────────────┐
│Keyword │ Type │ Size │ Example │
├─────────────────┼──────────────────────┼─────────┼─────────────────────────┤
│fileset │ │ │ │
│* tag │ tag_string │ 64 │ commands │
│ ancestor │ repeatable list │ │ product.oldfileset │
│ │ of product.fileset │ │ oldproduct.fileset │
│ architecture │ one_line_string │ 64 │ HP-UX_B.11.11_32/64 │
│ │ │ │ HP-UX_B.11.23_IA/PA │
│ category_tag │ tag_string │ 64 │ patch_normal │
│ corequisites │ software_spec │ │ SD.man,r>=2.0 │
│ description │ multi_line_string │ 8192 │ < data/descr.cmd │
│ dynamic_module │ one_line_string │ 256 │ ipf pfil │
│ exrequisite │ software_spec │ │ SD.man,r>=2.0 │
│ is_kernel │ boolean │ 9 │ false │
│ is_locatable │ boolean │ 9 │ false │
│ is_patch │ boolean │ 9 │ false │
│ is_reboot │ boolean │ 9 │ false │
│ is_sparse │ boolean │ 9 │ false │
│ machine_type │ uname_string │ 64 │ 9000/[78]?? │
│ │ │ │ ia64* │
│ os_name │ uname_string │ 64 │ HP-UX │
│ os_release │ uname_string │ 64 │ ?.11.* │
│ os_version │ uname_string │ 64 │ ? │
│ prerequisites │ software_spec │ │ SD.agent,r>=2.0 │
│* revision │ revision_string │ 64 │ 2.42 │
│ supersedes │ software_spec │ 8192 │ product.fileset, │
│ │ │ │ fr=revision │
│ title │ one_line_string │ 256 │ SD Commands │
│ control_files │ │ │ │
│ directory │ path_mapping_string │ │ ./commands = /usr/sbin │
│ file_permis_ │ permission_string │ │ -u 0222 -o root -g sys │
│ sions │ permission_string │ │ -u 0222 -o root -g sys │
│ file │ file_specification │ │ -m 04555 bin/swinstall │
│ │ │ │ (or) * │
│end │ │ │ │
└─────────────────┴──────────────────────┴─────────┴─────────────────────────┘
Control File Attributes
Control files can be defined within
filesets and/or products.
┌─────────────────┬────────────────┬─────────┬──────────────────────────┐
│Keyword │ Type │ Size │ Example │
├─────────────────┼────────────────┼─────────┼──────────────────────────┤
│ checkinstall │ path_string │ 1024 │ ./scripts/checkinstall │
│ checkremove │ path_string │ 1024 │ ./scripts/checkremove │
│ configure │ path_string │ 1024 │ ./scripts/configure │
│ control_file │ path_string │ 1024 │ ./scripts/subscripts │
│ postinstall │ path_string │ 1024 │ ./scripts/postinstall │
│ postremove │ path_string │ 1024 │ ./scripts/postremove │
│ preinstall │ path_string │ 1024 │ ./scripts/preinstall │
│ preremove │ path_string │ 1024 │ ./scripts/preremove │
│ request │ path_string │ 1024 │ ./scripts/request │
│ unconfigure │ path_string │ 1024 │ ./scripts/unconfigure │
│ unpreinstall │ path_string │ 1024 │ ./scripts/unpreinstall │
│ unpostinstall │ path_string │ 1024 │ ./scripts/unpostinstall │
│ verify │ path_string │ 1024 │ ./scripts/verify │
└─────────────────┴────────────────┴─────────┴──────────────────────────┘
Vendor-Defined Attributes
You can create your own software
attributes when packaging software.
Keywords in a product specification
file that are not recognized by SD
are preserved, along with their asso‐
ciated values, by being transferred
to the resulting INDEX or INFO files
created by (Refer to swpackage(4) for
more information on INDEX and INFO
files.)
The keyword is a filename character
string. The value associated with a
keyword is processed as an
attribute_value. It can be continued
across multiple input lines or can
reference a file containing the value
for the keyword.
Vendor-defined attributes are noted
during packaging or when modified
with These attributes can be listed
with
As always, use caution in construct‐
ing your Product Specification File.
If you misspell a standard keyword,
SD may mistake the keyword for a ven‐
dor-defined attribute.
VALUE TYPES
The value for each attribute must be
of a specific type. The types are:
Maximum length: 64 bytes
Examples: HP, SD
Tag strings contain
a subset of charac‐
ters.
The first character
is restricted to:
"A-Z", "a-z", "0-9"
The characters are
not allowed; see
ctype(3C).
Metacharacters not
allowed:
Shell metacharacters
not allowed:
Shell quoting char‐
acters not allowed:
Directory path char‐
acter not allowed:
Maxi‐
mum
length:
256
bytes
Examples: Hewlett-
Packard Company
One-line strings
support a subset of
characters only:
No characters,
except for space and
tab, are allowed.
Maximum length: 8192 bytes (1
Mb for
Multi-line strings
support all charac‐
ters. They repre‐
sent one or more
paragraphs of text.
They can be speci‐
fied in-line, sur‐
rounded by double-
quotes. They can
also be stored in a
file, and specified
using the ``format.
Maximum length: 64 bytes
Examples: 2.0,
B.11.11
Revision strings
contain zero or more
dot-separated
one_line_strings
(above).
Maximum length: 8 bytes
Examples: true,
false
One of the values
"true" or "false".
Maximum length: 255 bytes for
tapes, 1024 bytes for depots
Examples:
An absolute or rela‐
tive path to a file.
Many attributes of
this type are
restricted to 255
bytes in length.
This restriction is
due to the command,
which requires a
file's be <= 100
bytes, and a file's
to be <= 155 bytes.
(Some implementa‐
tions of enforce <
and not <=.)
Maximum length: 64 bytes
Examples: 9000/7*,
9000/8*, ia64*, HP-
UX, ?.11.*
Uname strings con‐
taining a subset of
characters only.
No characters are
allowed.
Shell pattern match‐
ing notation
allowed:
Patterns can be
"ORed" together
using the separator:
Maximum length: none
Examples:
A value of the form:
``where the source
defines the direc‐
tory in which subse‐
quently defined
files are located.
The optional desti‐
nation maps the
source to a destina‐
tion directory in
which the files will
actually be
installed.
Maximum length: none
Examples: or * (to
denote all files and
directories)
Explicitly specifies
a file or directory
to be packaged,
using the format:
The source and des‐
tination can be
paths relative to
source and destina‐
tion directories
specified in the
path_mapping_string.
You can also use to
include all files
below the source
directory specified
by a keyword.
Maximum length: none
Examples:
A value of the form:
where each component
defines a default
permissions value
for each file and
directory defined in
a fileset. The
default values can
be overridden in
each file's specific
definition. The
owner and group
fields are of type
tag_string. The uid
and gid fields are
of type unsigned
integer. To specify
a numeric username
on systems that sup‐
port numeric user‐
names for owners,
you must specify
both the numeric
owner username and
the uid. Similarly,
to specify a numeric
groupname, you must
specify both the
numeric group group‐
name and the gid.
If only one value is
supplied for
owner/group, it will
be interpreted as an
id if the value is
numeric. Otherwise,
it will be inter‐
preted as a name.
The mode and umask
are unsigned inte‐
gers, but only sup‐
ports the octal
character set:
"0"-"7".
Maximum length: none
Examples: SD.agent
or SD,r=2.0,a=HP-
UX_B.11.23_IA/PA
Software specifica‐
tions are used to
specify software in
dependencies, ances‐
tors and other
attributes, as well
as command line
selections. The SD
commands and
attributes support
the following syntax
for each soft‐
ware_specification:
· You can specify
selections with
the following
shell wildcard
and pattern-
matching nota‐
tions:
For example,
selects all bun‐
dles and products
with tags that
end with "man".
· Bundles and sub‐
products are
recursive. Bun‐
dles can contain
other bundles and
subproducts can
contain other
subproducts, for
example:
or (using expres‐
sions):
· The software
specification
selects all prod‐
ucts. Use this
specification
with caution.
The version compo‐
nent has the form:
· location applies
only to installed
software and
refers to soft‐
ware installed to
a location other
than the default
product direc‐
tory.
· and apply only to
filesets.
· , , , , and apply
only to bundles
and products.
They are applied
to the leftmost
bundle or product
in a software
specification.
· The <op> (rela‐
tional operator)
component can be
of the form:
or
which performs
individual com‐
parisons on dot-
separated fields.
For example,
chooses all revi‐
sions greater
than or equal to
The system com‐
pares each dot-
separated field
to find matches.
Shell patterns
are not allowed
with these opera‐
tors.
· The (equals)
relational opera‐
tor lets you
specify selec‐
tions with the
shell wildcard
and pattern-
matching nota‐
tions:
For example, the
expression
returns any revi‐
sion in version
10 or version 11.
· All version com‐
ponents are
repeatable within
a single specifi‐
cation (for exam‐
ple, If multiple
components are
used, the selec‐
tion must match
all components.
· include the and
version compo‐
nents even if
they contain
empty strings.
For installed
software, is also
included.
· No space or tab
characters are
allowed in a
software selec‐
tion.
· The software can
take the place of
the version com‐
ponent. It has
the form:
[instance_id]
within the con‐
text of an
exported catalog,
where is an inte‐
ger that distin‐
guishes versions
of products and
bundles with the
same tag.
PRODUCT SPECIFICATION FILE SEMANTICS
The following sections describe the
attributes which can be defined.
Distribution (Depot) Specification
The following is an example of a dis‐
tribution specification:
[<vendor specification>]
[<bundle specification>]
<product specification>
[<product specification>]
Keyword that begins the distribution
specification.
Each keyword defines an
attribute of the distribution
depot or tape itself. All
keywords are optional, even if
a distribution specification
is included in a PSF.
Defines the semantics to use when
parsing
the PSF. To ensure IEEE Stan‐
dard 1387.2 semantics, define
a of as the first attribute.
Defines the identifier (short name)
for the
distribution depot or tape.
Defines the
copyright information for the
distribution depot or tape;
the value is either the text
itself (within double-quotes)
or a pointer to the filename
containing the text.
Defines the multi-paragraph
description of the distribu‐
tion depot or tape; the value
is either the text itself
(within double-quotes) or a
pointer to the filename con‐
taining the text.
If a distribution specification is
included in the PSF,
requires only the keyword plus
one or more contained product
definitions. The keyword can
also be used in place of
Defines the
part or manufacturing number
of the distribution depot (for
example, CD-ROM or tape).
Defines the full name (one-line
description)
of the distribution depot or
tape.
Ends the distribution specification.
This keyword is optional.
Vendor Specification
The defined for the PSF file deter‐
mines how vendor specifications are
associated with products and bundles.
If a is not defined or is defined as
vendor specifications will be associ‐
ated with all subsequent products and
bundles that define a matching
attribute.
If a of is specified, all subsequent
products and bundles will automati‐
cally be assigned a from the last
vendor object defined at the distri‐
bution level, if any, or from a ven‐
dor object defined within a product
or bundle, unless a is explicitly
defined.
Note that the vendor specification is
not the same as vendor-defined
attributes described in the "Vendor-
Defined Attributes" section.
The following is an example of a ven‐
dor specification:
Each keyword defines an attribute of
a vendor object. If a vendor speci‐
fication is included in the PSF,
requires the and keywords.
Keyword that begins the vendor
specification.
Defines the identifier (short
name) for the vendor.
Defines the full name (one-
line description)
for the vendor.
Defines the multi-paragraph
description of the vendor; the
value is
either the text itself
(within double-quotes)
or a pointer to the
filename containing the
text.
Ends the vendor specification.
This keyword is optional.
Category Specification
The following is an example of a cat‐
egory specification.
Keyword that begins the cate‐
gory specification.
Defines the identifier (short
name) for the category.
Defines the full name (one
line description) for the cat‐
egory.
A more detailed description of
the category.
Determines which category
object definition to maintain
in a depot
when a definition being
installed or copied
does not match a defi‐
nition already in the
depot with the same
Ends the category specifica‐
tion. This keyword is
optional.
Bundle Specifications
The following are examples of a bun‐
dle specification:
Product Specifications
The following are examples of a prod‐
uct specification: Products are
assumed to be locatable unless they
explicitly define the is_locatable
attribute to Non-locatable products
must define this attribute.
+ [<control script specifications>]
+ [<subproduct specifications>]
+ <fileset specification>
+ [<fileset specification>]
+ [<control script specifications>]
+ [<subproduct specifications>]
+ <fileset specification>
+ [<fileset specification>]
Each keyword defines an attribute of
a product or bundle object. For each
product specified, requires only the
and keywords, plus one or more con‐
tained definitions. For each bundle
specified, requires the and keywords.
Required keyword that begins
the product specification.
Defines the identifier (short
name) for the
product or bundle.
Describes the target system(s)
on which the product or bundle
will run.
Provides a human-read‐
able summary of the
four attributes which
define the exact target
system(s) the product
supports.
Required keyword that begins
the bundle specification.
A repeatable tag-based
attribute identifying a set of
categories of which the
software object is a
member. This is used
as a selection mecha‐
nism and can be used
independent of patches.
The default value is an
empty list or if the
attribute is set to
Like this attribute can
be used as a pointer to
a category object that
contains additional
information about the
category (for example,
a one-line title defi‐
nition and a descrip‐
tion of the category).
Note that the category
tag is reserved. When
is set to a built-in
attribute of value is
automatically included.
NOTE: You can only
change the value by
performing a operation
or by using to change
the value of the
attribute.
The list of
(all version-distin‐
guishing attributes
included) for the bun‐
dle contents. The con‐
tents should also be at
the fileset level and
include all dependen‐
cies. More general
software_specs are also
supported, including
bundles containing
other bundles, but the
bundle contents might
vary between invoca‐
tions.
Defines the
copyright information
for the product or bun‐
dle; the value is
either the text itself
(within double-quotes)
or a pointer to the
filename containing the
text.
Defines the multi-paragraph
description of the
product or bundle; the
value is either the
text itself (within
double-quotes) or a
pointer to the filename
containing the text.
Defines the default, absolute
pathname to the directory in
which the
product's files will be
installed (that is, the
root directory of the
product). If this
attribute is not speci‐
fied, assigns a value
of "/".
Defines whether the product or
bundle can be installed into
any directory, or
whether it must be
installed into a spe‐
cific directory. If
this attribute is not
specified, assigns a
value of "true".
Identifies a software object
as a patch.
The default value is
When set to a built-in
attribute of value is
automatically included.
The version of the IEEE Stan‐
dard 1387.2 to which the HP-
specific
data_model_revision
conforms. Possible
values are (the default
value) or
Defines the machine(s) on
which the product will run.
(If not
specified, assigns a
value of "*", meaning
the product runs on all
machines.) If there
are multiple machine
platforms, use wild‐
cards or use the '|'
character to separate
them. This attribute
should pattern match to
the output of the com‐
mand on the supported
target machine(s).
Defines the part or order num‐
ber for the product.
Defines the operating sys‐
tem(s) on which the product
will run. (If not
specified, assigns a
value of "*", meaning
the product runs on all
operating systems.) If
there are multiple
operating systems, use
wildcards or use the
'|' character to sepa‐
rate them. This
attribute should pat‐
tern match to the value
of
on the supported target
system(s).
Defines the operating system
release(s) on which the prod‐
uct will run.
(If not specified,
assigns a value of "*",
meaning the product
runs on all releases.)
If there are multiple
operating system
releases, use wildcards
or use the '|' charac‐
ter to separate them.
This attribute should
pattern match to the
value of on the sup‐
ported target sys‐
tem(s).
Defines the operating system
version(s) on which the prod‐
uct will run.
(If not specified,
assigns a value of "*",
meaning the product
runs on all versions.)
If there are multiple
operating system ver‐
sions, use wildcards or
use the '|' character
to separate them. This
attribute should pat‐
tern match to the value
of on the supported
target system(s).
Defines a kernel build script
to be executed when kernel
filesets are
loaded. (Kernel file‐
sets have the attribute
set to The default ker‐
nel script is (See
mk_kernel(1M) for more
information.) The
default script executes
when the attribute is
not specified. Only
one kernel build script
is allowed per product,
and the script executes
only once, even if
defined for multiple
filesets.
Defines the
README information for
the product or bundle;
the value must be a
pointer to the filename
containing the text.
Defines the
revision (release num‐
ber, version number) of
the product or bundle.
Defines the full name (one-
line description)
of the product or bun‐
dle.
Associates this product or
bundle with the last defined
vendor object, if that
object has a matching
attribute.
Ends the product or bundle
specification.
This keyword is
optional.
Subproduct Specification
The following is an example of a sub‐
product specification:
Each keyword defines an attribute of
a subproduct object. If a subproduct
is specified, requires the and key‐
words.
Keyword that begins the sub‐
product specification.
Defines the identifier (short
name) for the
subproduct.
Defines the filesets or sub‐
products that make up a sub‐
product.
(Subproducts can con‐
tain other subprod‐
ucts.) The value is a
whitespace separated
list of fileset or sub‐
product values. In the
PSF, fileset defini‐
tions are not contained
within subproduct defi‐
nitions. The keyword
is used to assign file‐
sets to subproducts.
Defines the multi-paragraph
description of the sub‐
product; the value is
either the text itself
(within double-quotes)
or a pointer to the
filename containing the
text.
Defines the full name (one-
line description)
of the subproduct.
Ends the subproduct specifica‐
tion.
This keyword is
optional.
Fileset Specification
The following are examples of a file‐
set specification:
[<control file specifications>]
[<dependency specifications>]
[<file specifications>]
[<control file specifications>]
[<dependency specifications>]
[<file specifications>]
Each keyword defines an attribute of
a fileset object. For each fileset
specified, requires the fileset and
tag keywords, plus zero or more file
specifications.
You can define additional disk space
requirements for the fileset using a
control_file. (See the section for
more information.)
Keyword that begins fileset
specification.
Defines the identifier (short
name) for the
fileset.
Describes the target system(s)
on which the fileset will run
if
filesets for multiple
architecture are
included in a single
product. Provides a
human-readable summary
of the four attributes
which define the exact
target system(s) the
product supports. Many
filesets do not include
an architecture; only a
product architecture
need be defined.
A list of filesets that will
match the current fileset when
installed
on a target system, if
the installation option
is specified. Also
determines the base to
which a patch is
applied.
A repeatable tag-based
attribute identifying a set of
categories of which the
software object is a
member. This is used
as a selection mecha‐
nism and can be used
independent of patches.
The default value is an
empty list or if the
attribute is set to
Like this attribute can
be used as a pointer to
a category object that
contains additional
information about the
category (for example,
a one-line title defi‐
nition and a descrip‐
tion of the category).
Note that the category
tag is reserved. When
is set to a built-in
attribute of value is
automatically included.
You can only change the
value by performing a
operation or by using
to change the value of
the attribute.
Defines the multi-paragraph
description of the
fileset; the value is
either the text itself
(within double-quotes)
or a pointer to the
filename containing the
text.
A space-separated list of
strings specifies the list of
dynamic_modules
(DLKMs) packaged into
the fileset. For 11.23
and newer releases, the
dynamic modules them‐
selves must be deliv‐
ered to If the
dynamic_module
attribute is ommitted,
no DLKMs may be deliv‐
ered in the fileset.
When a dynamic module
is packaged, it is cus‐
tomary to include a
call to the con‐
trol_util mod_system‐
file in a postinstall
script to link the mod‐
ule to the kernel. If
a state of static is
specified in the
mod_systemfile call,
the attributes is_ker‐
nel and is_reboot must
also be set to true.
In addition, if a sys‐
tem reboot is needed to
activate the module,
the is_reboot attribute
must be set to true.
A value of "true"
defines the fileset as
being a contributor to
the operating system
kernel; the target sys‐
tem(s) kernel build
process will be invoked
after the fileset is
installed. If this
attribute is not speci‐
fied, assumes a default
value of "false".
Defines whether the fileset
can be installed into any
directory, or
whether it must be
installed into a spe‐
cific directory. If
this attribute is not
specified, assigns a
value of
Identifies a software object
as a patch. The default value
is
When set to a built-in
attribute of value is
automatically included.
A value of "true"
declares that the file‐
set requires a system
reboot after installa‐
tion. If this
attribute is not speci‐
fied, assumes a default
value of "false".
Indicates that a fileset con‐
tains only a subset of files
in the
base (ancestor) fileset
and that the contents
are to be merged with
the base fileset. The
default value is If the
attribute is is also
set to for the fileset,
although it can be
forced to false.
Defines the machine(s) on
which the files will run if a
fileset
architecture has been
defined. (If not spec‐
ified, assigns a value
of "*", meaning the
files run on all
machines.) If there
are multiple machine
platforms, use wild‐
cards or use the '|'
character to separate
them. This attribute
should pattern match
the output of the com‐
mand on the supported
target machine(s).
Defines the operating sys‐
tem(s) on which the files will
run if a
fileset architecture
has been defined. (If
not specified, assigns
a value of "*", meaning
the files run on all
operating systems.) If
there are multiple
operating systems, use
wildcards or use the
'|' character to sepa‐
rate them. This
attribute should pat‐
tern match to the value
of
on the supported target
system(s).
Defines the operating system
release(s) on which the files
will run.
(If not specified,
assigns a value of "*",
meaning the files run
on all releases.) If
there are multiple
operating system
releases, use wildcards
or use the '|' charac‐
ter to separate them.
This attribute should
pattern match to the
value of on the sup‐
ported target sys‐
tem(s).
Defines the operating system
version(s) on which the files
will run.
(If not specified,
assigns a value of "*",
meaning the files runs
on all versions.) If
there are multiple
operating system ver‐
sions, use wildcards or
use the '|' character
to separate them. This
attribute should pat‐
tern match to the value
of on the supported
target system(s).
Defines the
revision (release num‐
ber, version number) of
the fileset.
Used when a patch is replaced
by (or merged into) a later
patch.
The attribute indicates
which previous patches
are replaced by the
patch being installed
or copied. This
attribute value is a
list of software speci‐
fications of other
patches that this patch
"supersedes".
Defines the full name (one-
line description)
of the fileset.
Ends the fileset specifica‐
tion. This keyword is
optional.
Dependency Specification
You can add optional dependency
information to a fileset definition
if installation or execution of a
fileset depends on the presence or
absence of another fileset:
A list of software that must
be installed
before the current
fileset can be
installed.
A list of software that can be
installed at the same time as
the
current fileset but
must be present before
the current fileset can
be run.
A list of software that may
not be installed before
or at the same time the
current fileset is
installed.
If a dependency is not met, SD pre‐
vents the fileset from being
installed.
The following is an example of a
dependency specification:
Each keyword/value defines a depen‐
dency relationship on another soft‐
ware object. The object can be
within the same product as the depen‐
dent fileset, or it can be within
another product.
Multiple dependency specifications
are allowed. You can use them to
define AND relationships between the
dependencies. (The AND relationship
is implied because all dependencies
must be satisfied.)
You can also define OR relationships
using the '|' character. White spa‐
ces are not allowed around the OR
character, and OR dependencies are
resolved from left to right. For
example:
Note that if you specify a dependency
for a fileset and the fileset is
superseded by another fileset as part
of a patch, SD will still recognize
the dependency.
Control Script Specification
Control scripts are often referred to
as control_files, although con‐
trol_files may include non-script
files such as space files, INDEX
files, and INFO files.
Control_file syntax is:
source[=tag][filename]
Where tag is the script name.
You can also list each item on a sep‐
arate line:
The following is an example of con‐
trol script specifications:
For control scripts:
· Each script specification
defines a control script
object. The value of each
keyword is the source file‐
name for the control file.
· Control scripts are
optional. If present,
copies the specified source
filename into the depot's
storage directory for the
associated product or file‐
set.
· You can use the keyword to
define scripts or sub‐
scripts. If the basename
of the source path is a
standard keyword, then SD
executes that script. For
example:
scripts/script1=check‐
install
scripts/script2=con‐
figure
· You can define the physical
name of a control script in
a depot. This lets you
define a control file with
a filename different than
its tag, lets multiple con‐
trol scripts point at the
same file, and lets a sin‐
gle script contain steps
for all scripts. (The
environment variable tells
the script which tag is
being executed.) For exam‐
ple, the following specifi‐
cation defines the same
file for use by multiple
scripts:
scripts/myscript
common
scripts/myscript
common
scripts/myscript=pre‐
install common
scripts/myscript=con‐
figure common
SD supports the following types of
control scripts:
Defines the installation check
script
executed by This script
is executed during the
analysis of each tar‐
get, and it checks that
the installation can be
attempted. If the
product or fileset
check script returns 1
the product or fileset
(respectively) will not
be installed. If it
returns 11 no products
will be installed.
Defines the remove check
script executed by
This script is executed
during the analysis of
each target, and it
checks that the remove
can be attempted. If
the check script
returns 1 (ERROR), the
product or fileset will
not be removed.
Defines an arbitrary control
file to be included with the
product or fileset and
stored alongside the
named control files.
It is used to include a
subscript called by the
named scripts or a data
file read by these
scripts. If the
optional component of
the value is not speci‐
fied, uses the of the
source as the for the
control file. Other‐
wise, the value is
used.
Defines the configuration
script executed by
and This script config‐
ures the target host
for the product or
fileset (and the prod‐
uct or fileset for any
required information
about the target host).
Defines the fix script run by
to correct and report
problems on installed
software. The fix
script can create miss‐
ing directories, cor‐
rect file modifications
(mode, owner, group,
major, and minor), and
recreate symbolic
links.
Defines the installation post-
load script
executed by A fileset
script is executed
immediately after the
fileset files are
loaded. A product
script is executed
after all filesets for
that product have been
installed.
Defines the post-remove script
executed by A fileset
script is executed
immediately after the
fileset files are
removed. A product
script is executed
after all filesets for
that product have been
removed.
Defines the installation pre-
load script executed by
A fileset script is
executed immediately
before the fileset
files are loaded. A
product script is exe‐
cuted before any file‐
sets for that product
have been installed.
Defines the pre-remove script
executed by
A fileset script is
executed immediately
before the fileset
files are removed. A
product script is exe‐
cuted before any file‐
sets for that product
have been removed.
The only script that may be
interactive. This script may
be run by
or after selection and
before the analysis
phase in order to
request information
from the administrator
that will be needed for
the configure_script
when that script is run
later. The
request_script writes
all information into
the response_file,
which the scripts can
then use.
A data file to define addi‐
tional disk space require‐
ments. See
Space_Files for more
information.
Defines the un-configuration
script executed by
and This script uncon‐
figures the target host
for the product or
fileset, undoing the
configuration performed
by the script.
Defines the installation pre-
restore script
executed by A fileset
script is executed
immediately before the
fileset files are
restored if there is an
error and the option is
set to true. Note that
scripts are supported
for filesets only. It
should undo the steps
taken by the script.
Defines the installation post-
restore script
executed by A fileset
script is executed
immediately after the
fileset files are
restored if there is an
error and the option is
set to true. A product
script is executed
after all filesets for
that product have been
restored. It should
undo the steps taken by
the scripts.
Defines the verification
script executed by
This script verifies
the configuration per‐
formed by the script.
Space Files
The control_file is not a script. It
lets you define additional disk space
requirements for the filesets and
notes positive disk space impact on
any directory or file that results
from the actions of control scripts.
Each fileset or product may contain a
space file. Comments are allowed
starting with # character. The space
file lists a path and a byte size for
each path:
For each directory or file path
listed in the space file, adds the
size in bytes to the disk space
requirements. The size reflects the
maximum transient or permanent disk
space required for the install.
Script Interpreter
By default, SD interprets scripts
with a POSIX shell Control scripts
can also define their own interpreter
in the first line of the script. You
can use the keyword to define a dif‐
ferent interpreter for specific
scripts. The syntax is:
For example:
SD checks that the interpreter is
available. If not, the script fails.
If SD finds the interpreter, it pro‐
cesses the script normally using the
specified interpreter.
You can use a checkinstall script to
verify the existence of any script
interpreters that you specify.
Environment Variables for Scripts
The following environment variables
affect scripts:
Holds the path to the
Installed Products Database
(IPD), relative to
the path in the envi‐
ronment variable. Note
that you can specify a
path for the IPD using
the default option.
Defines the current directory
of the script being executed,
either a
temporary catalog
directory, or a direc‐
tory within in the
Installed Products
Database (IPD). This
variable tells scripts
where other control
scripts for the soft‐
ware are located (for
example, subscripts).
Holds the tag name of the
control_file being exe‐
cuted. When packaging
software, you can
define a physical name
and path for a control
file in a depot. This
lets you define the
control_file with a
name other than its tag
and lets you use multi‐
ple control file defi‐
nitions to point to the
same file. A con‐
trol_file can query the
variable to determine
which tag is being exe‐
cuted.
Defines the location of the
product, which may have been
changed from
the default product
directory. When com‐
bined with the this
variable tells scripts
where the product files
are located.
A variable which defines
a minimum set of com‐
mands available for use
in a control script
(for example,
Defines the root directory in
which the session is operat‐
ing, either
or an alternate root
directory. This vari‐
able tells control
scripts the root direc‐
tory in which the prod‐
ucts are installed. A
script must use this
directory as a prefix
to to locate the prod‐
uct's installed files.
The configure script is
only run when is
Contains the pathname of a
file containing the value of
every option
for a particular com‐
mand, including soft‐
ware and target selec‐
tions. This lets
scripts retrieve any
command options and
values other than the
ones provided explic‐
itly by other environ‐
ment variables. For
example, when the file
pointed to by is made
available to a request
script, the targets
option contains a list
of software_collec‐
tion_specs for all tar‐
gets specified for the
command. When the file
pointed to by is made
available to other
scripts, the targets
option contains the
single software_collec‐
tion_spec for the tar‐
gets on which the
script is being exe‐
cuted.
This variable contains the
fully qualified software spec‐
ification of
the current product or
fileset. The software
specification allows
the product or fileset
to be uniquely identi‐
fied.
File Specification
Within a fileset specification, the
user can specify the following file
types to be packaged into the fileset
by
control file
directory
hard link
regular file
symbolic link
An error results if you specify a
recognized but unpackageable type or
an unrecognized type.
The command supports these mechanisms
for specifying the files contained in
a fileset:
Default permission specifica‐
tion
For some or all of the
files and directories
in the fileset, the
user can define a
default set of permis‐
sions.
Directory mapping
The user can point at a
source directory in
which the fileset's
files are located. In
addition, the user can
map this source direc‐
tory to the appropriate
(destination) directory
in which this subset of
the product's files
will be located.
Explicit file specification
For some or all of the
files and directories
in the fileset, the
user can name each
source file and desti‐
nation location.
Recursive (implicit) file
specification
If a directory mapping
is active, the user can
tell to include all
files and directories
in the fileset (recur‐
sively) below the spec‐
ified directory.
These mechanisms can all be used in
combination with the others.
Directory Mapping
The keyword defines a directory under
which subsequently listed files are
located. In addition, the user can
map the directory to a directory
under which the packaged files will
be installed. For example, the defi‐
nition:
causes all files from the directory
to have the prefix when installed.
The directory must be a located
within the attribute, if defined.
(This attribute is defined by the
keyword in the product specifica‐
tion.)
The destination directory must be an
absolute pathname.
The keyword is optional.
Recursive File Specification
The keyword directs to recursively
include every file (and directory)
within the current source directory
in the fileset. (Partial wildcarding
is not supported— for example, to
indicate all files starting with
"dm".)
The keyword must have been previously
specified before the specification
can be used.
All attributes for the destination
file object are taken from the source
file, unless a keyword is active
(this keyword is described below).
The user can specify multiple
pairs to gather files from different
source directories into a single
fileset.
Explicit File Specification
Instead of, or in addition to, the
recursive file specification, the
user can explicitly specify the files
and directories to be packaged into a
fileset.
The user can use the directory key‐
word to define a source (and destina‐
tion) for explicitly specified files.
If no directory keyword is active,
then the source path and the absolute
destination path must be specified
for each file.
(See the section for sample file
specifications.)
An explicit file specification uses
this form:
Specifies an existing file or
directory
(perhaps within the
currently active source
directory) to include
in the fileset.
Defines the relative or abso‐
lute path to the source file.
If this is a relative
path, will search for
it relative to the
source directory set by
the directory keyword.
If no source directory
is active, will search
for it relative to the
current working direc‐
tory in which the com‐
mand was invoked.
All attributes for the
destination file object
are taken from the
source file, unless a
keyword is active, or
the or options are also
included in the file
specification.
Defines the destination path
at which the file will be
installed.
If is a relative path,
the active destination
directory set by the
keyword will be pre‐
fixed to it. If it is
a relative path, and no
destination directory
is active, generates an
error. If the destina‐
tion is not specified,
the source is used as
the destination, with
the appropriate mapping
done with the active
destination directory
(if any).
Defines the (octal) mode of a
file or directory.
Defines the destination file's
owner name and/or or uid.
If only the owner is
specified, the owner
and uid attributes are
set for the destination
file object, based on
the packaging host's If
only the uid is speci‐
fied, it is set as the
uid attribute for the
destination object and
no owner name is
assigned. If both are
specified, each sets
the corresponding
attribute for the file
object. To specify a
numeric username on
systems that support
numeric user names for
owners, you must spec‐
ify both the numeric
owner username and the
uid. If only one value
is supplied for owner,
it will be interpreted
as an id if the value
is numeric. Otherwise,
it will be interpreted
as a name. During an
installation, the owner
attribute is used to
set the owner name and
uid, unless the owner
name is not defined in
the target system's In
this case, the uid
attribute is used to
set the uid.
Defines the destination file's
group name and/or or gid. If
only the
group is specified, the
group and gid
attributes are set for
the destination file
object, based on the
packaging host's If
only the group is spec‐
ified, and it contains
digits only, it is
interpreted as the gid,
and is set as the gid
attribute for the des‐
tination object; no
group name is assigned
to the object. If both
are specified, each
sets the corresponding
attribute for the file
object. To specify a
numeric groupname on
systems that support
numeric group names for
groups, you must spec‐
ify both the numeric
group groupname and the
gid. If only one value
is supplied for group,
it will be interpreted
as an id if the value
is numeric. Otherwise,
it will be interpreted
as a name. During an
installation, the group
attribute is used to
set the group name and
gid, unless the group
name is not defined in
the target system's In
this case, the gid
attribute is used to
set the gid.
Defines a file of type
d (directory), h (hard
link), or s (symbolic
link). Caution, some
releases of swpackage
do not work correctly
with type, see section
for details.
If only
source is speci‐
fied, it is used
as the destina‐
tion path at
which the direc‐
tory will be
created, and
nothing is
accessed on the
packaging sys‐
tem. If source
and filename are
specified,
source is used
to retrieve the
attributes for
the directory to
be created at
filename, unless
redefined by
mode_options.
Both source and file‐
name must be
specified. The
source path must
be the installed
location of a
regular file
elsewhere in the
fileset. At
install time the
hard link will
be created at
filename. Noth‐
ing is accessed
on the packaging
system.
Both source and file‐
name must be
specified. At
install time the
symbolic link
will be created
at filename to
point to source.
The source
string can be a
relative or
absolute path,
and that string
is not modified
in any way
before being
used as the path
pointed to by
the installed
symbolic link.
Nothing is
accessed on the
packaging sys‐
tem.
Marks the file as volatile,
meaning it can be modified
(that is,
deleted) after
installed without
impacting the fileset.
When processing existing files in a
source directory, a number of prob‐
lems may be encountered. Errors or
warning messages are printed for each
problem. (The command terminates
when errors are encountered in read‐
ing the PSF or accessing the source
files.)
Default Permission Specification
By default, a destination file object
will inherit the mode, owner, and
group of the source file. The key‐
word can be specified to set a
default permission umask/mode, owner,
and group for all the files being
packaged into the fileset. This
includes files specified by that do
not exist before packaging. (See the
section for sample permission speci‐
fications.)
Applies only to the fileset it
is defined in.
Multiple can be speci‐
fied, later definitions
simply replace previous
definitions.
Defines a default (octal) mode
for all file objects.
Instead of specifying an octal
mode as the default, the user
can specify
an octal value which
gets "subtracted" from
an existing source
file's mode to generate
the mode of the desti‐
nation file.
By specifying a the
user can set a default
mode for executable
files, non-executable
files, and directories.
(A specific mode can be
set for any file, as
described above.)
Defines the destination file's
owner name and/or or uid (as
defined above).
Defines the destination file's
group name and/or or gid (as
defined above).
Defines the destination file's
type (as defined above). Cau‐
tion,
some releases of
swpackage do not work
correctly with type,
see section for
details.
PSF Extensions
A PSF can contain extended file defi‐
nitions. SD currently supports and
files.
Exclude files let you explicitly
exclude files that would otherwise be
included in the PSF. The syntax is:
An exclude file can only be specified
after a file definition. The file
listed after the keyword is excluded
from the current context (for exam‐
ple, from a recursive file definition
or wildcard).
If the filename specifies a direc‐
tory, then all files below that
directory are excluded.
Include files let you include file
definitions from a separate file.
The syntax is:
The include file must be separated
from the keyword by a less than sign
EXAMPLES
This example illustrates a typical
PSF.
Example File Specifications
The following examples illustrate the
use of the and keywords:
Include all files under to be rooted
under
Include only certain files under and
to be rooted under and
Explicitly list files and directo‐
ries, no directory mapping specified:
Use all specification types to
include files:
Redefine specific files previously
defined using (for example, to set
explicit attributes):
Example Permission Specifications
The following examples illustrate the
use of the file_permission keyword.
Set a read only 444 mode for all file
objects (requires override for every
executable file and directory):
Set a read mode for non-executable
files, and a read/execute mode for
executable files and for directories:
Set the same mode defaults, plus an
owner and group:
Set the same mode defaults, plus a
uid and gid:
Set the same mode defaults, plus
owner/uid and group/gid combinations:
Set the same mode defaults, plus
numeric owner/uid and numeric
group/gid combinations:
Set the owner write permission's in
addition to the above:
If the user defines no file_permis‐
sions, uses the default value:
for destination file objects based on
existing source files. (Meaning the
mode, owner/uid, group/gid are set
based on the source file, unless spe‐
cific overrides are specified for a
destination file.)
WARNINGS
Some releases of do not work cor‐
rectly with the -t type construct in
a PSF. The program in the HP-UX 11i
v1 (11.11) PHCO_34295 patch, 11i v1
(11.11) OEUR available after the
patch, 11i v2 (11.23) March 2006
OEUR, and newer releases work cor‐
rectly with all -t type usages. If a
specific use of -t type creates pack‐
ages that are correct, all releases
of other Software Distributor com‐
mands such as swlist, swcopy, swin‐
stall, etc, can be used with those
packages.
AUTHOR
was developed by the Hewlett-Packard
Company and Mark H. Colburn (see
pax(1)).
SEE ALSOswpackage(1M), sd(4), sd(5).
available at
SD customer web site at
swpackage(4)
