|
» |
|
|
|
NAMEswpackage — product specification file (PSF) format DESCRIPTIONIntroductionThe
swpackage
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
tar
and
cpio
tape depots. See
sd(4)
for details on tape format. The software is organized into a four-level hierarchy of software objects:
bundles,
products,
subproducts,
and
filesets.
Bundles and subproducts are recursive: a bundle can contain 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
Product Specification File
(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 VersionSD object and attribute syntax conforms to the
layout_version 1.0
specification of the
IEEE POSIX 1387.2 Software Administration
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
version. 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
layout_version
option for
swpackage,
swmodify,
swcopy,
and
swlist. The version used by
swpackage
can be also controlled by specifying the
layout_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
swpackage
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
category and category_title
attributes within the bundle or product class). Patch-handling attributes, including
applied_patches, is_patch, and patch_state. The fileset
architecture
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 follows:
Replaces the depot
media_sequence_number
with the
media
object with a
sequence_number
attribute. Replaces the
vendor
definition within products and bundles with a
vendor_tag
attribute and a corresponding
vendor
object defined outside the product or bundle. Pluralizes the
corequisite
and
prerequisite
fileset attributes (to
corequisites
and
prerequisites). Changes the
timestamp
attribute to
mod_time.
PRODUCT SPECIFICATION FILE SYNTAXA 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
swpackage
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
subsequent 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
keyword
is an identifier for the attribute. Some attributes allow multiple values. You can specify values with a
keyword/list syntax:
keyword value1 value2 value3 ... You can also use a list following the keyword: 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:
- "This is an example of a
- two-line value."
Double quotes (") are optional when defining a value
that contains embedded whitespace.
Attribute TableThe 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 associated values. Attribute
keywords have one or more values. Attributes marked with a
*
determine the uniqueness of a product, bundle, or fileset. Their
values may also be of the type
version_component
when used in a version component of a software specification. control_files
can be defined within products or filesets or both. You can define your own attributes.
See
Vendor-Defined Attributes
for more information.
Attribute Table (continued)Attribute Table (continued)
Control File AttributesControl files can be defined within filesets and/or products.
Vendor-Defined AttributesYou 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 associated values, by
being transferred to the resulting INDEX or INFO files created by
swpackageor
swcopy.
(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
swmodify.
These attributes can be listed with
swlist. As always, use caution in constructing your Product Specification
File. If you misspell a standard keyword, SD may mistake the keyword
for a vendor-defined attribute. VALUE TYPESThe value for each attribute must be of a specific type. The types are:
- tag_string
Maximum length: 64 bytes Examples: HP, SD Tag strings support a subset of
isascii()
characters only: Requires one or more characters from: "A-Z", "a-z", "0-9", including the
first character. The
isspace()
characters are not allowed. SDU metacharacters not allowed:
. , : = Shell metacharacters not allowed:
# ; & ( ) { } | < > Shell quoting characters not allowed:
" ` '\ Directory path character not allowed:
/ - one_line_string
Maximum length: 256 bytes Examples: Hewlett-Packard Company One-line strings support a subset of
isascii()
characters only: No
isspace()
characters, except for space and tab, are allowed. - multi_line_string
Maximum length: 8192 bytes (1Mb for
readme) Multi-line strings support all
isascii()
characters. They
represent one or more paragraphs of text. They can be specified
in-line, surrounded by double-quotes. They can also be stored in
a file, and specified using the ``< filename''
format. - revision_string
Maximum length: 64 bytes Examples: 2.0, B.11.11 Revision strings contain zero or more dot-separated one_line_strings (above). - boolean
Maximum length: 8 bytes Examples: true, false One of the values "true" or "false". - path_string
Maximum length: 255 bytes for tapes, 1024 bytes for depots Examples:
/usr,
/mfg/sd/scripts/configure An absolute or relative path to a file.
Many attributes of this type are restricted to 255
bytes in length. This restriction is due to the
tar(1)
command, which requires a file's
basename(1)
be <= 100 bytes, and a file's
dirname(1)
to be <= 155 bytes. (Some implementations of
tar
enforce < and not <=.) - uname_string
Maximum length: 64 bytes Examples: 9000/7*, 9000/8*, ia64*, HP-UX, ?.11.* Uname strings containing a subset of
isascii()
characters only. No
isspace()
characters are allowed. Shell pattern matching notation allowed:
[ ] * ? ! Patterns can be "ORed" together using the separator:
| - path_mapping_string
Maximum length: none Examples:
/mfg/sd/files/usr = /usr A value of the form: ``source[=destination]''
where the source defines the directory in which subsequently
defined files are located. The optional destination maps the
source to a destination directory in which the files will
actually be installed. - file_specification
Maximum length: none Examples:
-m 04555 sbin/swinstall
or * (to denote all files and directories) Explicitly specifies a file or directory to be packaged, using the format:
[-m mode] [-o [owner[,]][uid]]
[-g [group[,]][gid]] [-v] [source] [destination] The source and destination can be paths relative to source and
destination directories specified in the
path_mapping_string. You can also use
*
to include all files below the source directory specified by a
directory
keyword. - permission_string
Maximum length: none Examples:
-u 0222 -o root -g sys A value of the form:
[-m mode|-u umask ] [-o [owner[,]][uid]]
[-g [group[,]][gid]] 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. The
mode and umask are unsigned integers, but only supports the octal
character set: "0"-"7". - software_specification
Maximum length: none Examples: SD.agent or SD,r=2.0,a=HP-UX_B.11.23_IA/PA Software specifications are used to specify software in dependencies, ancestors and other
attributes, as well as command line selections.
The SD
commands and attributes support the following syntax for each
software_specification:
bundle[.product[.subproduct][.fileset]][,version]
product[.subproduct][.fileset][,version]
The
=
(equals) relational operator lets you specify selections with the
following shell wildcard and pattern-matching notations:
For example,
*man
selects all bundles and products with tags that end with "man". Bundles
and
subproducts
are recursive.
Bundles
can contain other
bundles
and
subproducts
can contain other
subproducts,
for example:
bun1.bun2.prod.sub1.sub2.fset,r=1.0
or (using expressions):
bun[12].bun?.prod.sub*,a=HP-UX
The
\*
software specification selects all products. Use this specification
with caution.
The
version
component has the form:
[,r <op> revision][,a <op> arch][,v <op> vendor]
[,c <op> category][,q=qualifier][,l=location]
[,fr <op> revision][,fa <op> arch]
location
applies only to installed software and refers to software installed to
a location other than the default product directory. fr
and
fa
apply only to filesets. r
,
a
,
v
,
c
, and
l
apply only to bundles and products. They are applied to the
leftmost bundle or product in a software specification. The
<op>
(relational operator) component can be of the form:
which performs individual comparisons on dot-separated fields. For example,
r>=B.10.00
chooses all revisions greater than or equal to
B.10.00.
The system compares each dot-separated field to find
matches. Shell patterns are not allowed with these operators. The
=
(equals) relational operator lets you specify selections with the
shell wildcard and pattern-matching notations:
For example, the expression
r=1[01].*
returns any revision in version 10 or version 11. All version components are repeatable within a single specification (e.g.
r>=B.12,
r<B.20).
If multiple components are used, the selection must match all
components. Fully qualified software specs
include the
r=,
a=,
and
v=
version components even if they contain empty strings. For installed
software,
l=
is also included. No space or tab characters are allowed in a software selection. The software
instance_id
can take the place of the version component. It has the form:
within the context of an exported catalog, where
instance_id
is an integer that distinguishes versions of products and bundles with
the same tag.
PRODUCT SPECIFICATION FILE SEMANTICSThe following sections describe the attributes which can be defined. Distribution (Depot) SpecificationThe following is an example of a distribution specification: distribution or depot
layout_version 1.0
tag APPLICATIONS_CD
copyright < data/copyright.cd
description < data/description.cd
number B2358-13601
title HP-UX Applications Software Disc
[<vendor specification>]
...
[<bundle specification>]
...
<product specification>
[<product specification>]
...
end
- distribution or depot"
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. - layout_version
Defines the semantics to use when parsing
the PSF.
To ensure IEEE Standard 1387.2 semantics, define a
layout_version
of
1.0,
as the first attribute. - tag
Defines the identifier (short name) for the
distribution depot or tape. - copyright
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. - description
Defines the multi-paragraph
description of the distribution depot or tape;
the value is either the text itself (within double-quotes) or a pointer
to the filename containing the text. - distribution
If a distribution specification is included in the PSF,
swpackage
requires only the
keyword plus one or more contained product definitions.
The
depot
keyword can also be used in place of
distribution. - number
Defines the
part or manufacturing number of the distribution depot (e.g. CD-ROM) or tape. - title
Defines the full name (one-line description)
of the distribution depot or tape. - end
Ends the distribution specification. This keyword is optional.
Vendor SpecificationThe
layout_version
defined for the PSF file determines how vendor specifications are
associated with products and bundles.
If a
layout_version
is not defined or is defined as
1.0,
vendor specifications will be associated with
all subsequent products and bundles that define a matching
vendor_tag
attribute. If a
layout_version
of
0.8
is specified, all subsequent products and bundles will automatically
be assigned a
vendor_tag
from the last vendor object defined at the distribution level, if any,
or from a vendor object defined within a product or bundle, unless a
vendor_tag
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 vendor specification: vendor
tag HP
description < data/description.hp
title Hewlett-Packard Company
end Each keyword defines an attribute of a vendor object. If a vendor
specification is included in the PSF,
swpackage
requires the
vendor
and
tag
keywords.
- vendor
Keyword that begins the vendor specification. - tag
Defines the identifier (short name) for the vendor. - title
Defines the full name (one-line description)
for the vendor. - description
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. - end
Ends the vendor specification. This keyword is optional.
Category SpecificationThe following is an example of a category specification. category
tag
title
description
revision
end
- category
Keyword that begins the category specification. - tag
Defines the identifier (short name) for the category. - title
Defines the full name (one line description) for the category. - description
A more detailed description of the category. - revision
Determines which category object definition to maintain in a depot
when a definition being installed or copied does not match a
definition already in the depot with the same
category_tag. - end
Ends the category specification. This keyword is optional.
Bundle SpecificationsThe following are examples of a bundle specification: bundle
tag SD
architecture HP-UX_B.11.11_32/64
category_tag Ordered Apps
contents prod.fs1.r=1.0,a=,v=
copyright <data/copyright.sd
description < data/description.sd
layout_version 1.0
machine_type 9000/[78]??
number B2001A
os_name HP-UX
os_release ?.11.*
os_version *
revision A.01.00
title Software Distributor
vendor_tag HP
end bundle
tag SD
architecture HP-UX_B.11.23_IA/PA
category_tag Ordered Apps
contents prod.fs1.r=1.0,a=,v=
copyright <data/copyright.sd
description < data/description.sd
layout_version 1.0
machine_type ia64*
number B2001A
os_name HP-UX
os_release ?.11.*
os_version *
revision A.01.00
title Software Distributor
vendor_tag HP
end Product SpecificationsThe following are examples of a product specification:
Products are assumed to be locatable unless they explicitly
define the
is_locatable
attribute to
false.
Non-locatable products must define this attribute. product tag SD
architecture HP-UX_B.11.11_32/64
category_tag Ordered Apps
contents prod.fs1.r=1.0,a=,v=
copyright <data/copyright.sd
description <data/description.sd
directory /
is_locatable false
is_patch false
layout_version 1.0
machine_type 9000/[78]??
number B2001A
os_name HP-UX
os_release ?.11.*
os_version *
postkernel /usr/lbin/kernel_build
readme < data/README.sd
revision A.01.00
title Software Distributor
vendor_tag HP
+ [<control script specifications>]
+ [<subproduct specifications>]
+ <fileset specification>
+ [<fileset specification>]
...
end product tag SD
architecture HP-UX_B.11.23_IA/PA
category_tag Ordered Apps
contents prod.fs1.r=1.0,a=,v=
copyright <data/copyright.sd
description <data/description.sd
directory /
is_locatable false
is_patch false
layout_version 1.0
machine_type ia64*
number B2001A
os_name HP-UX
os_release ?.11.*
os_version *
postkernel /usr/lbin/kernel_build
readme < data/README.sd
revision A.01.00
title Software Distributor
vendor_tag HP
+ [<control script specifications>]
+ [<subproduct specifications>]
+ <fileset specification>
+ [<fileset specification>]
...
end Each keyword defines an attribute of a product or bundle object. For
each product specified,
swpackage
requires only the
product
and
tag
keywords, plus one or more contained
fileset
definitions. For each bundle specified,
swpackage
requires the
bundle,
tag,
and
contents
keywords.
- product
Required keyword that begins the product specification. - tag
Defines the identifier (short name) for the
product or bundle. - architecture
Describes the target system(s) on which the product or bundle will run.
Provides a human-readable summary of the four
uname(1)
attributes which define the exact target system(s) the product
supports. - bundle
Required keyword that begins the bundle specification.
- category_tag
A repeatable tag-based attribute identifying a set of
categories of which the software object is a member. This is used
as a selection mechanism and can be used independent of
patches. The default value is an empty list or
patch
if the
is_patch
attribute is set to
true. Like
vendor_tag,
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
definition and a
description
of the category). Note that the category tag
patch
is reserved. When
is_patch
is set to
true,
a built-in
category_tag
attribute of value
patch
is automatically included. NOTE:
You can only change the
patch
value by performing a
swpackage
operation or by using
swmodify
to change the value of the
is_patch
attribute.
- contents
The list of
fully qualified software_specs
(all version-distinguishing attributes included) for the bundle
contents. The contents should also be at the fileset level and include
all dependencies. More general
software_specs
are also supported, including bundles containing other bundles, but
the bundle contents might vary between invocations. - copyright
Defines the
copyright information for the product or bundle;
the value is either the text itself (within double-quotes) or a pointer
to the filename containing the text. - description
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. - directory
Defines the default, absolute pathname to the directory in which the
product's files will be installed (i.e. the root directory of the
product).
If this
attribute is not specified,
swpackage
assigns a value of "/". - is_locatable
Defines whether the product or bundle can be installed into any directory, or
whether it must be installed into a specific directory.
If this
attribute is not specified,
swpackage
assigns a value of "true". - is_patch
Identifies a software object as a patch.
The default value is
false.
When set to
true,
a built-in
category_tag
attribute of value
patch
is automatically included. - layout_version
The version of the IEEE Standard 1387.2 to which the HP-specific
data_model_revision conforms. Possible values are
1.0
(the default value) or
0.8. - machine_type
Defines the machine(s) on which the product will run. (If not
specified,
swpackage
assigns a value of "*", meaning the product runs on all machines.) If
there are multiple machine platforms, use wildcards or use the '|'
character to separate them. This attribute should pattern match to
the output of the
model
command on the supported target machine(s). - number
Defines the part or order number for the product. - os_name
Defines the operating system(s) on which the product will run. (If not
specified,
swpackage
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 separate them. This attribute should
pattern match to the value of
uname -s [: getconf KERNEL_BITS]
on the supported target system(s). - os_release
Defines the operating system release(s) on which the product will run.
(If not specified,
swpackage
assigns a value of "*", meaning the product
runs on all releases.) If there are multiple operating system releases,
use wildcards or use the '|' character to separate them. This attribute
should pattern match to the value of
uname -r
on the supported target system(s). - os_version
Defines the operating system version(s) on which the product will run.
(If not specified,
swpackage
assigns a value of "*", meaning the product
runs on all versions.) If there are multiple operating system versions,
use wildcards or use the '|' character to separate them. This attribute
should pattern match to the value of
uname -v
on the supported target system(s). - postkernel
Defines a kernel build script to be executed when kernel filesets are
loaded. (Kernel filesets have the
is_kernel
attribute set to
true .)
The default kernel script is
/usr/sbin/mk_kernel.
(See
mk_kernel(1M)
for more information.) The default script executes when the
postkernel
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. - readme
Defines the
README information for the product or bundle;
the value must be a pointer
to the filename containing the text. - revision
Defines the
revision (release number, version number) of the product or bundle. - title
Defines the full name (one-line description)
of the product or bundle. - vendor_tag
Associates this product or bundle with the last defined
vendor object, if that object has a matching
tag
attribute. - end
Ends the product or bundle specification.
This keyword is optional.
Subproduct SpecificationThe following is an example of a subproduct specification: subproduct
tag Manager
contents commands agent data man
description < data/description.manager
title Management Utilities
end Each keyword defines an attribute of a subproduct object. If a
subproduct is specified,
swpackage
requires the
subproduct,
tag,
and
contents
keywords.
- subproduct
Keyword that begins the subproduct specification. - tag
Defines the identifier (short name) for the
subproduct. - contents
Defines the filesets or subproducts that make up a subproduct.
(Subproducts can contain other subproducts.) The value is a
whitespace separated list of fileset or subproduct
tag
values. In the PSF, fileset definitions are not contained within
subproduct definitions. The
contents
keyword is used to assign filesets to subproducts. - description
Defines the multi-paragraph
description of the subproduct;
the value is either the text itself (within double-quotes) or a pointer
to the filename containing the text. - title
Defines the full name (one-line description)
of the subproduct. - end
Ends the subproduct specification.
This keyword is optional.
Fileset SpecificationThe following are examples of a fileset specification: fileset
tag commands
ancestor newprod.fs
architecture HP-UX_B.11.11_32/64
category_tag system_mgt
description < data/description.commands
is_kernel false
is_locatable false
is_patch false
is_reboot false
is_sparse false
machine_type 9000/[78]??
os_name HP-UX
os_release ?.11.*
os_version ?
revision 2.15
supersedes product.fileset,fr=revision
title Commands (management utilities)
[<control file specifications>]
[<dependency specifications>]
[<file specifications>]
end fileset
tag commands
ancestor newprod.fs
architecture HP-UX_B.11.23_IA/PA
category_tag system_mgt
description < data/description.commands
is_kernel false
is_locatable false
is_patch false
is_reboot false
is_sparse false
machine_type ia64*
os_name HP-UX
os_release ?.11.*
os_version ?
revision 2.15
supersedes product.fileset,fr=revision
title Commands (management utilities)
[<control file specifications>]
[<dependency specifications>]
[<file specifications>]
end Each keyword defines an attribute of a fileset object. For each
fileset specified,
swpackage
requires the
fileset
and
tag
keywords, plus zero or more file specifications. You can define additional disk space requirements for the fileset
using a
space
control_file. (See the
Control Script Specification
section for more
information.)
- fileset
Keyword that begins fileset specification. - tag
Defines the identifier (short name) for the
fileset. - architecture
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
uname(1)
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. - ancestor
A list of filesets that will match the current fileset when installed
on a target system, if the
match_target
installation option is specified. Also determines the base to which a
patch is applied. - category_tag
A repeatable tag-based attribute identifying a set of
categories of which the software object is a member. This is used
as a selection mechanism and can be used independent of
patches. The default value is an empty list or
patch
if the
is_patch
attribute is set to
true. Like
vendor_tag,
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
definition and a
description
of the category). Note that the category tag
patch
is reserved. When
is_patch
is set to
true,
a built-in
category_tag
attribute of value
patch
is automatically included. NOTE:
You can only change the
patch
value by performing a
swpackage
operation or by using
swmodify
to change the value of the
is_patch
attribute. - description
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. - dynamic_module
A space-separated list of strings specifies the list of dynamic_modules
(DLKMs) packaged into the fileset. The dynamic modules themselves must
be delivered to
/stand/mod/.
If the dynamic_module attribute is ommitted,
no DLKMs may be delivered in the fileset. When a dynamic module is packaged, it is customary to include a call to
the control_util mod_systemfile in a postinstall script to link the module
to the kernel. If a state of static is specified in the mod_sytemfile call,
the attributes is_kernel and is_reboot must also be set to true.
In addition, if a system reboot is needed to activate the module, the is_reboot
attribute must be set to true. - is_kernel
A value of "true"
defines the fileset as being a contributor to the operating system kernel;
the target system(s) kernel build process will be invoked after the fileset
is installed.
If this attribute is not specified,
swpackage
assumes a default value of "false". - is_locatable
Defines whether the fileset can be installed into any directory, or
whether it must be installed into a specific directory. If this
attribute is not specified,
swpackage
assigns a value of
true. - is_patch
Identifies a software object as a patch. The default value is
false.
When set to
true,
a built-in
category_tag
attribute of value
patch
is automatically included. - is_reboot
A value of "true"
declares that the fileset requires a system reboot after installation.
If this attribute is not specified,
swpackage
assumes a default value of "false". - is_sparse
Indicates that a fileset contains 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
false.
If the
is_patch
attribute is
true,
is_sparse
is also set to
true
for the fileset, although it can be forced to false. - machine_type
Defines the machine(s) on which the files will run if a fileset
architecture has been defined. (If not
specified,
swpackage
assigns a value of "*", meaning the files run on
all machines.) If there are multiple machine platforms, use wildcards
or use the '|' character to separate them. This attribute should pattern
match the output of the
model
command on the supported target machine(s). - os_name
Defines the operating system(s) on which the files will run if a
fileset architecture has been defined. (If not
specified,
swpackage
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 separate them. This attribute should
pattern match to the value of
uname -s [: getconf KERNEL_BITS]
on the supported target system(s). - os_release
Defines the operating system release(s) on which the files will run.
(If not specified,
swpackage
assigns a value of "*", meaning the files
run on all releases.) If there are multiple operating system releases,
use wildcards or use the '|' character to separate them. This attribute
should pattern match to the value of
uname -r
on the supported target system(s). - os_version
Defines the operating system version(s) on which the files will run.
(If not specified,
swpackage
assigns a value of "*", meaning the files
runs on all versions.) If there are multiple operating system versions,
use wildcards or use the '|' character to separate them. This attribute
should pattern match to the value of
uname -v
on the supported target system(s). - revision
Defines the
revision (release number, version number) of the fileset. - supersedes
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 specifications of other patches that this
patch "supersedes". - title
Defines the full name (one-line description)
of the fileset.
- end
Ends the fileset specification. This keyword is optional.
Dependency SpecificationYou 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: - prerequisites
A list of software that must be installed
before
the current fileset can be installed. - corequisites
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. - exrequisites
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 prevents the fileset from being
installed. The following is an example of a dependency specification: corequisites SD.data
...
prerequisites productA,r>=2.1
...
exrequisites productB,r>=2.1
... Each keyword/value defines a dependency relationship on another
software object. The object can be within the same product as the
dependent 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
spaces are not allowed around the OR character, and OR dependencies
are resolved from left to right. For example:
prerequisites ProdA|ProdB|BundleA|ProdC.FS
corequisites ProdX|ProdY|BundleZ|ProdW.FS
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 SpecificationControl scripts are often referred to as control_files, although
control_files may include non-script files such as space files, INDEX
files, and INFO files. Control_file syntax is:
control_file
source[=tag][filename] Where
tag
is the script name.
You can also list each item on a separate line: control_file
source filename
tag tag_name The following is an example of control script specifications: checkinstall scripts/checkinstall
checkremove scripts/checkremove
configure scripts/configure
fix scripts/fix
postinstall scripts/postinstall
postremove scripts/postremove
preinstall scripts/preinstall
preremove scripts/preremove
request scripts/request
unconfigure scripts/unconfigure
unpostinstall scripts/postinstall
unpreinstall scripts/preinstall
verify scripts/verify
space space For control scripts:
Each script specification defines a control script object. The value
of each keyword is the source
filename
for the control file. Control scripts are optional. If present,
swpackage
copies the specified source
filename
into the depot's storage directory for the associated product or fileset. You can use the keyword
control_file
to define scripts or subscripts. If the basename of the source path is
a standard keyword, then SD executes that script. For example:
- control_file
scripts/script1=checkinstall - control_file
scripts/script2=configure
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 control scripts point at the same file, and lets a
single script contain steps for all scripts. (The
SW_CONTROL_TAG
environment variable tells the script which tag is being executed.)
For example, the following specification defines the same file for use
by multiple scripts:
- checkinstall
scripts/myscript common - checkremove
scripts/myscript common - control_file
scripts/myscript=preinstall common - control_file
scripts/myscript=configure common
SD supports the following types of control scripts:
- checkinstall
Defines the installation check script
executed by
swinstall.
This script is executed during the analysis of each target, and it
checks that the installation can be attempted. If the product or
fileset check script returns 1
(ERROR),
the product or fileset
(respectively) will not be installed. If it returns 11
(GLOBAL_ERROR),
no products will be installed. - checkremove
Defines the remove check script executed by
swremove.
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. - control_file
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
tag
component of the value is not specified,
swpackage
uses the
basename(1)
of the source
filename
as the
tag
for the control file.
Otherwise, the
tag
value is used. - configure
Defines the configuration script executed by
swinstall
and
swconfig.
This script configures the target host for the product or fileset (and the
product or fileset for any required information about the target host). - fix
Defines the fix script run by
swverify
to correct and report problems on installed software. The fix script
can create missing directories, correct file modifications (mode,
owner, group, major, and minor), and recreate symbolic links. - postinstall
Defines the installation post-load script
executed by
swinstall.
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. - postremove
Defines the post-remove script
executed by
swremove.
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. - preinstall
Defines the installation pre-load script executed by
swinstall.
A fileset script is executed immediately before the fileset files are
loaded. A product script is executed before any filesets for that
product have been installed. - preremove
Defines the pre-remove script executed by
swremove.
A fileset script is executed immediately before the fileset files are
removed. A product script is executed before any filesets for that
product have been removed. - request
The only script that may be interactive. This script may be run by
swask,
swinstall,
or
swconfig
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. - space file
A data file to define additional disk space requirements. See
Space_Files
for more information. - unconfigure
Defines the un-configuration script executed by
swremove
and
swconfig.
This script unconfigures the target host for the product or fileset,
undoing the configuration performed by the
configure
script. - unpostinstall
Defines the installation pre-restore script
executed by
swinstall.
A fileset script is executed immediately before the fileset files
are restored if there is an error and the
autorecover_product
option is set to true.
Note that
unpostinstall
scripts are supported for filesets only.
It should undo the steps taken by the
postinstall
script. - unpreinstall
Defines the installation post-restore script
executed by
swinstall.
A fileset script is executed immediately after the fileset files
are restored if there is an error and the
autorecover_product
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
preinstall
scripts. - verify
Defines the verification script executed by
swverify.
This script verifies the configuration performed by the
configure
script.
Space FilesThe
space
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: #Reserve 2000 bytes in /tmp and /opt
/tmp/space_dummy1 2000
/opt/space_dummy2 2000
#Reserve another 3000 bytes in /tmp
/tmp/space_dummy3 3000
#Reserve 4000 in /mydir
/mydir/ 4000 For each directory or file path listed in the space file,
swinstall
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 InterpreterBy default, SD interprets scripts with a POSIX shell
(sh).
Control scripts can also define their own interpreter in the first
line of the script. You can use the
interpreter
keyword to define a different interpreter for specific scripts. The
syntax is:
interpreter interpreter_name For example: control_file
source scripts
tag checkinstall
interpreter ksh SD checks that the interpreter is available. If not, the script
fails. If SD finds the interpreter, it processes 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 ScriptsThe following environment variables affect scripts: - SW_CATALOG
Holds the path to the Installed Products Database (IPD), relative to
the path in the
SW_ROOT_DIRECTORY
environment variable. Note that you
can specify a path for the IPD using the
installed_software_catalog
default option. - SW_CONTROL_DIRECTORY
Defines the current directory of the script being executed, either a
temporary catalog directory, or a directory within in the Installed
Products Database (IPD). This variable tells scripts where other
control scripts for the software are located (e.g. subscripts). - SW_CONTROL_TAG
Holds the tag name of the
control_file
being executed. 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 multiple control file definitions to
point to the same file. A
control_file
can query the
SW_CONTROL_TAG
variable to determine which tag is being executed. - SW_LOCATION
Defines the location of the product, which may have been changed from
the default product directory. When combined with the
SW_ROOT_DIRECTORY,
this variable tells scripts where the product files are located. - SW_PATH
A
PATH
variable which defines a minimum set of
commands available for use in a control script
(e.g.
/sbin:/usr/bin). - SW_ROOT_DIRECTORY
Defines the root directory in which the session is operating, either
/
or an alternate root directory.
This variable tells control scripts the root directory in which the
products are installed. A script must use this directory as a prefix to
SW_LOCATION
to locate the product's installed files.
The configure script is only run when
SW_ROOT_DIRECTORY
is
/. - SW_SESSION_OPTIONS
Contains the pathname of a file containing the value of every option
for a particular command, including software and target
selections. This lets scripts retrieve any command
options and values other than the ones provided explicitly by
other environment variables. For example, when the file pointed to by
SW_SESSIONS_OPTIONS
is made available to a
request
script, the
targets
option contains a list of
software_collection_specs
for all targets specified for the command. When the file pointed to by
SW_SESSIONS_OPTIONS
is made available to other scripts, the
targets
option contains the single
software_collection_spec
for the targets on which the script is being executed. - SW_SOFTWARE_SPEC
This variable contains the fully qualified software specification of
the current product or fileset. The software specification allows the
product or fileset to be uniquely identified.
File SpecificationWithin a fileset specification, the user can specify the following file
types to be packaged into the fileset by
swpackage:
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
swpackage
command supports these mechanisms for specifying the files contained in
a fileset:
- Default permission specification
For some or all of the files and directories in the fileset,
the user can define a
default set of permissions. - Directory mapping
The user can point
swpackage
at a source directory in which the fileset's files are located. In
addition, the user can map this source directory 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 destination location. - Recursive (implicit) file specification
If a directory mapping is active, the user can tell
swpackage
to include all files and directories in the fileset
(recursively) below the specified directory.
These mechanisms can all be used in combination with the others. Directory MappingThe
directory source[=destination]
keyword defines a
source
directory under which subsequently listed files are located.
In addition, the user can map the
source
directory to a
destination
directory
under which the packaged files will be installed.
For example, the definition:
directory ./commands = /usr/sbin causes all files from the
./commands
directory to have the prefix
/usr/sbin
when installed.
The
destination
directory must be
a located within the
product.directory
attribute, if defined. (This attribute is defined by the
directory
keyword in the product specification.) The
destination
directory must be an absolute pathname.
The
directory
keyword is optional. Recursive File SpecificationThe
file *
keyword directs
swpackage
to recursively include every file (and directory) within the current
source directory in the fileset.
(Partial wildcarding is not supported—e.g.,
file dm*
to indicate all files starting with "dm".) The
directory
keyword must have been previously specified before the
file *
specification can be used. All attributes for the destination file object are taken from the source
file, unless a
file_permissions
keyword
is active (this keyword is described below). The user can specify multiple
directory source[=destination]
file * pairs to gather files from different source directories into a single
fileset. Explicit File SpecificationInstead 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
keyword to define a source (and destination) 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
EXAMPLES
section for sample file specifications.) An explicit file specification uses this form:
file [-m mode] [-o [owner[,]][uid]] [-g [group[,]][gid]] [-t type]
[-v] [source] [destination] - file
Specifies an existing file or directory
(perhaps within the currently active source
directory) to include in the fileset. - source
Defines the relative or absolute path to the source file. If this is a relative path,
swpackage
will search for it relative to the source directory set by
the
directory
keyword. If no source directory is active,
swpackage
will search for it
relative to the current working directory in which the command was invoked. All attributes for the destination file object are taken from the source
file, unless a
file_permissions
keyword
is active, or the
-m,
-o,
or
-g,
options are also included in the file specification. - destination
Defines the destination path at which the file will be installed.
If
destination
is a relative path, the active destination directory set by the
directory
keyword will be prefixed to it. If it is a relative path, and no
destination directory is active,
swpackage
generates an error. If the destination is not specified, the
source
is used as the
destination,
with the appropriate mapping done with the active destination directory
(if any). - -m mode
Defines the (octal) mode of a file or directory. - -o [owner[,]][uid]
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
/etc/passwd.
If only the uid is specified, 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.
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
/etc/passwd.
In this case, the
uid
attribute is used to set the uid. - -g [group[,]][gid]
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
/etc/group.
If only the group is specified, and it contains digits only, it is interpreted
as the gid, and is set as the
gid
attribute for the destination object; no group name is assigned to the
object. If both are specified, each sets the corresponding attribute
for the file object.
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
/etc/group.
In this case, the
gid
attribute is used to set the gid. - -t type [ mode_options ] source [ filename ]
Defines a file of type
d
(directory),
h
(hard link), or
s
(symbolic link). Caution, some releases of swpackage do not work
correctly with
-t
type,
see
WARNINGS
section for details.
- d Create a directory
If only
source
is specified, it is used as the destination path at which
the directory will be created, and nothing is accessed on
the packaging system. 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.
- h Create a hard link
Both
source
and
filename
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.
Nothing is accessed on the packaging system.
- s Create a symbolic link
Both
source
and
filename
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 system.
- -v
Marks the file as volatile, meaning it can be modified (i.e.
deleted) after installed without impacting the fileset.
When processing existing files in a source directory, a number of
problems may be encountered. Errors or warning messages are printed for each
problem. (The
swpackage
command terminates when errors are encountered in reading the PSF or accessing
the source files.) Default Permission SpecificationBy default, a destination file object will inherit the mode, owner,
and group of the source file. The
file_permissions
keyword 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
-t
that do not exist before packaging.
(See the
EXAMPLES
section for sample permission specifications.)
file_permissions [-m mode|-u umask] [-o[owner[,]][uid]] \
[-g[group[,]][gid]] [-t type] - file_permissions
Applies only to the fileset it is defined in.
Multiple
file_permissions
can be specified, later definitions simply replace previous definitions. - -m mode
Defines a default (octal) mode for all file objects. - -u umask
Instead of specifying an octal mode as the default, the user can specify
an octal
umask(1)
value which gets "subtracted" from an existing source file's mode
to generate the mode of the
destination file. By specifying a
umask,
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.) - -o [owner[,]][uid]
Defines the destination file's owner name and/or or uid (as defined above). - -g [group[,]][gid]
Defines the destination file's group name and/or or gid (as defined above). - -t type
Defines the destination file's type (as defined above). Caution,
some releases of swpackage do not work correctly with
-t
type,
see
WARNINGS
section for details.
PSF ExtensionsA PSF can contain extended file definitions. SD currently supports
exclude
and
include
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
exclude
keyword is excluded from the current context (for example, from a
recursive file definition or wildcard). If the filename specifies a directory, 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
file
keyword by a less than sign
(<). EXAMPLESThis example illustrates a typical PSF.
# PSF file which defines an example product.
depot
layout_version 1.0
# Vendor definition:
vendor
tag HP
title Hewlett-Packard Company
description < data/descr.hp
category
tag system_mgt
title Systems Management Applications
description These are the system management applications
revision 1.0
end
# Product definition:
product
tag SD
revision B.01.00
architecture HP-UX_B.11.23_IA/PA
vendor_tag HP
title HP Software Distributor
number B2001A
category_tag system_mgt
description < data/descr.sd
copyright < data/copyr.sd
readme < data/README.sd
machine_type *
os_name HP-UX
os_release ?.11.*
os_version ?
directory /
is_locatable false
# Create a product script which executes during the swremove
# analysis phase. (This particular script returns an ERROR,
# which prevents the removal of the SD product.)
checkremove scripts/checkremove.sd
# Subproduct definitions:
subproduct
tag Manager
title Management Utilities
contents commands agent data man
end
subproduct
tag Agent
title Agent component
contents agent data man
end
# Fileset definitions:
fileset
tag commands
title SD Commands (management utilities)
revision 2.42
description < data/descr.commands
# Dependencies
corequisites SD.data
corequisites SD.agent
# Control files:
configure scripts/configure.commands
# Files:
directory ./commands=/usr/sbin
file swinstall
file swcopy
...
directory ./nls=/usr/lib/nls/C
file swinstall.cat
file swpackage.cat
directory ./ui=/usr/lib/sw/ui
file *
...
end # commands
... # other filesets
fileset
tag man
title Manual pages for the Software Distributor
revision 2.05
directory ./man/man1m=/usr/man/man1m.Z
file *
directory ./man/man4=/usr/man/man4.Z
file *
directory ./man/man5=/usr/man/man5.Z
file *
end # man
end # SD Example File SpecificationsThe following examples illustrate the use of the
directory
and
file
keywords: Include all files under
./commands/,
to be rooted under
/usr/sbin/:
directory ./commands=/usr/sbin
file * Include only
certain files under
./commands/
and
./nls,
to be rooted under
/usr/sbin/
and
/usr/lib/nls/C/:
directory ./commands=/usr/sbin
file sbin/swinstall
file sbin/swcopy
...
directory ./nls=/usr/lib/nls/C/
file swinstall.cat
file swremove.cat
... Explicitly list files and directories, no directory mapping specified:
file ./commands/swinstall /usr/sbin/swinstall
...
file ./nls /usr/lib/nls/C
file ./nls/swinstall.cat /usr/lib/nls/C/swinstall.cat Use all specification types to include files:
directory ./commands=/usr/sbin
file *
directory ./nls=/usr/lib/nls/C
file swinstall.cat
...
file ./obam/obam.dm /etc/interface.lib/obam/obam.dm Redefine specific files previously defined using
file *
(e.g. to set explicit attributes):
directory ./commands=/usr/sbin
file *
file -m 04500 swcommand
file -o adm -g sys swfile Example Permission SpecificationsThe 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:
file_permissions -u 222 -o bin -g bin Set the same mode defaults, plus a uid and gid:
file_permissions -u 222 -o 2 -g 2 Set the owner write permission in addition to the above:
file_permissions -u 022 -o 2 -g 2 If the user defines no
file_permissions,
swpackage
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
specific overrides are specified for a destination file.) WARNINGSSome releases of
swpackage
do not work correctly with the
-t type
construct in a PSF. The
swpackage
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 correctly with all
-t type
usages.
If a specific use of
-t type
creates packages that are correct, all releases of other Software
Distributor commands such as swlist, swcopy, swinstall, etc, can be used with those
packages. AUTHORswpackage
was developed by the Hewlett-Packard Company and Mark H. Colburn (see
pax(1)). SEE ALSOswpackage(1M),
sd(4),
sd(5). Software Distributor Administration Guide,
available at
http://docs.hp.com. SD customer web site at
http://docs.hp.com/en/SD/.
|