Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX Reference > S

swpackage(4)

HP-UX 11i Version 3: February 2007
» 

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Index

NAME

swpackage — product specification file (PSF) format

DESCRIPTION

Introduction

The 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 Version

SD 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 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 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

keyword value

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 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 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.

KeywordTypeSizeExample
distribution   
layout_versionrevision_string641.0
tag tag_string64EXAMPLE_DEPOT
copyright multi_line_string8192< data/copyr.depot
description multi_line_string8192< data/descr.depot
number one_line_string64B2358-13601
title one_line_string256Example packages
end   
vendor   
tag tag_string64HP
description multi_line_string8192< data/descr.hp
title one_line_string256Hewlett-Packard Co.
end   
category   
tag tag_string64patch_normal
description multi_line_string8192For normal problems
revision revision_string640.0
title one_line_string256Category of Patches
end   
bundle   
* tag tag_string64SD
* architecture one_line_string64HP-UX_B.11.11_32/64
  HP-UX_B.11.23_IA/PA
category_tag one_line_string64OrderedApps
contents repeatable list8192pr.fs.r=1.0,a=,v=
copyright multi_line_string8192<data/copyr.sd
description multi_line_string8192<data/descr.sd
layout_version revision_string641.0
machine_type uname_string649000/[78]??
  ia64*
number one_line_string64B2001A
os_name uname_string64HP-UX
os_release uname_string64?.11.*
os_version uname_string64*
revision revision_string64A.01.00
title one_line_string256Software Distributor
vendor_tag tag_string64HP
end    

Attribute Table (continued)

KeywordTypeSizeExample
product   
* tag tag_string64SD
* architecture one_line_string64HP-UX_B.11.11_32/64
  HP-UX_B.11.23_IA/PA
category_tag one_line_string64OrderedApps
contents repeatable list8192pr.fs.r=1.0,a=,v=
copyright multi_line_string8192<data/copyr.sd
description multi_line_string8192<data/descr.sd
directory path_string1024/
is_locatable boolean9false
is_patch boolean9false
layout_version revision_string641.0
machine_type uname_string649000/[78]??
  ia64*
number one_line_string64B2001A
os_name uname_string64HP-UX
os_release uname_string64?.11.*
os_version uname_string64*
postkernel path_string255/usr/bin/kernel_build
readme multi_line_string1024<data/README.sd
revision revision_string64A.01.00
title one_line_string256Software Distributor
* vendor_tag tag_string64HP
control_files   
end    
subproduct   
tag tag_string64Manager
contents one-line list of commands agent data
tag_string values data man
description multi_line_string8192< data/desc.mgr
title one_line_string256Management Utilities
end   

Attribute Table (continued)

KeywordTypeSizeExample
fileset   
* tag tag_string64commands
ancestor repeatable list product.oldfileset
of product.fileset oldproduct.fileset
architecture one_line_string64HP-UX_B.11.11_32/64
  HP-UX_B.11.23_IA/PA
category_tag tag_string64patch_normal
corequisites software_spec SD.man,r>=2.0
description multi_line_string8192< data/descr.cmd
dynamic_moduleone_line_string256ipf pfil
exrequisite software_spec SD.man,r>=2.0
is_kernel boolean9false
is_locatable boolean9false
is_patch boolean9false
is_reboot boolean9false
is_sparse boolean9false
machine_type uname_string649000/[78]??
  ia64*
os_name uname_string64HP-UX
os_release uname_string64?.11.*
os_version uname_string64?
prerequisites software_spec SD.agent,r>=2.0
* revision revision_string642.42
supersedes software_spec8192product.fileset,
  fr=revision
title one_line_string256SD 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.

KeywordTypeSizeExample
checkinstall path_string1024./scripts/checkinstall
checkremove path_string1024./scripts/checkremove
configure path_string1024./scripts/configure
control_file path_string1024./scripts/subscripts
postinstall path_string1024./scripts/postinstall
postremove path_string1024./scripts/postremove
preinstall path_string1024./scripts/preinstall
preremove path_string1024./scripts/preremove
request path_string1024./scripts/request
unconfigure path_string1024./scripts/unconfigure
unpreinstall path_string1024./scripts/unpreinstall
unpostinstall path_string1024./scripts/unpostinstall
verify path_string1024./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 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 TYPES

The 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:

    • ==, >=, <=, <, >, or !=

    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:

    • [instance_id]

    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 SEMANTICS

The following sections describe the attributes which can be defined.

Distribution (Depot) Specification

The 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 Specification

The 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 Specification

The 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 Specifications

The 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 Specifications

The 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 Specification

The 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 Specification

The 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 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:

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:

  • corequisites P.F

  • 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 Specification

Control 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 Files

The 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 Interpreter

By 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 Scripts

The 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 Specification

Within 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 Mapping

The 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 Specification

The 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 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 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 Specification

By 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 Extensions

A 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:

exclude filename

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:

file < include_file

The include file must be separated from the file keyword by a less than sign (<).

EXAMPLES

This 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 Specifications

The 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 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):

file_permissions -m 444

Set a read mode for non-executable files, and a read/execute mode for executable files and for directories:

file_permissions -u 222

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:

file_permissions -u 000

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.)

WARNINGS

Some 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.

AUTHOR

swpackage was developed by the Hewlett-Packard Company and Mark H. Colburn (see pax(1)).

SEE ALSO

swpackage(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/.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1983-2007 Hewlett-Packard Development Company, L.P.