User Commandspkgsend(1)NAMEpkgsend - image packaging system publication client
SYNOPSIS
/usr/bin/pkgsend [options] command [cmd_options] [operands]
/usr/bin/pkgsend refresh-index
/usr/bin/pkgsend open [-en] pkg_fmri
/usr/bin/pkgsend add action arguments
/usr/bin/pkgsend include [-d basedir] ... [-T pattern] [manifest] ...
/usr/bin/pkgsend publish [-d basedir] ... [-T pattern] [--no-index]
[--fmri-in-manifest | pkg_fmri] [--no-catalog] [manifest] ...
/usr/bin/pkgsend close [-A | --no-index] [--no-catalog]
/usr/bin/pkgsend generate [-T pattern] [--target file] bundlefile ...
/usr/bin/pkgsend import [-T pattern] [--target file] bundlefile ...
DESCRIPTIONpkgsend allows the publication of new packages and new package
versions to an image packaging repository. Each publication is
structured as a transaction; multiple invocations of pkgsend
through a transaction allow the addition of resources and the
transaction submission. To create or manage repositories, see
pkgrepo(1).
OPTIONS
The following options are supported:
-s repo_uri A URI representing the location of the target
repository. Both HTTP and filesystem-based
publication are supported. The default value is
http://localhost:10000/.
For filesystem-based publication, the repo_uri
should be specified as follows:
file://<absolute_path_to_repository>
See the NOTES section below for more information
about restrictions or suggestions for publication.
--help or -?
Displays a usage message.
SUBCOMMANDS
The following subcommands are supported:
open [-en] pkg_fmri
Begin a transaction on the package and version specified by
pkg_fmri.
By default, or if the -e option is given, a successfully
opened transaction's ID will be published in a form suitable
for use with eval(1), to set the PKG_TRANS_ID environment
variable. This form can be convenient for delivering a
package transaction from a shell script, for example. If the
-n option is given, the transaction ID is displayed as a
string; this may be more useful in situations where shell
scripting is not an available option.
add action arguments
Add a resource associated with an action to the current
transaction. Requires transaction context. See ACTIONS
below.
import [-T pattern] [--target file] bundlefile ...
Add each given bundlefile into the current transaction.
Supported bundle types are:
- filesystem format SVr4 packages
- datastream format SVr4 packages
- tar files
- directories
If the basename of files in the bundle match the pattern(s)
specified with -T, the timestamp of the file is added to the
action for that file. The pattern uses shell matching rules:
* matches everything
? matches any single character
[seq] matches any character in seq
[!seq] matches any character not in seq
When the bundle is a directory, there is no clear way to
distinguish a file action from a hardlink action when there are
multiple pathnames for a single inode. Normally, the first one
found in the filesystem walk is treated as a file and the rest as
hardlinks. This may be arbitrary, depending on the
implementation of the filesystem. To specify which pathnames
should be treated as files, pass each pathname as an argument to
the --target option. This option has no effect on other bundle
types, as they are capable of expressing which pathnames are
files and which are hardlinks.
include [-d basedir] ... [-T pattern] [manifest] ...
Add resources associated with the multiple actions present in
each manifest file to the current transaction. If no files
are specified, the standard input is read. Each line in the
file should be the string representation of an action. In
particular, the "add" token as described above should not be
present, nor should there be open and close tokens representing
transaction boundaries. For those actions with datastreams, the
path to the file containing the data should be the second word on
the line; for file actions if this is set to "NOHASH" the value of
the "path" attribute is used instead.
If the user specifies the -d option, basedir is prepended to
the search path when locating files in the manifest. Multiple
-d options have their directories searched in the order they
appear on the command line.
The -T option works as in the import command.
close [-A] [--no-index]
Close current transaction. With -A, abandon the current
transaction. With --no-index, do not update the
repository's search indices. With --no-catalog, do not add
to catalog which for now is only effective with file:// scheme
repositories. This improves performance when publishing
many packages at once; the repository will need to be
started with a --add-content flag (see pkg.depotd(1M) man
page) to catalog and index the new content.
publish [ -d basedir] ... [-T pattern] [--no-index]
[--fmri-in-manifest | fmri] [--no-catalog] [manifest] ...
Combines open, include and close in a single operation. -d
and --no-index options behave as described for include and
close subcommands. With --fmri-in-manifest, use the fmri
specified in the package manifest w/ a set action name of
"pkg.fmri". Otherwise the fmri must be specified on the
command line. With --no-catalog (which has effect only w/
file:// scheme repositories), do not update the catalog with
the new package. This improves performance when publishing
many packages at once; the repository will need to be started
with a --add-content flag (see pkg.depotd(1M) man page) to
catalog and index the new content.
The -T option works as in the import command.
generate [-T pattern] [--target file] bundlefile ...
Read each given bundlefile (such as an SVR4 package, directory,
tarfile, etc) and emit the manifest describing the bundlefile to
the stdout. The -T and --target options work as in the import
command. The repo argument or PKG_TRANS_ID is not used with this
subcommand. Once obtained, the manifest can be annotated, have
dependencies analyzed, added, etc before being passed to the
publish or import subcommands.
refresh-index
Update the repository's search indices. Should be used after
closing one or more transactions using --no-index.
ENVIRONMENT VARIABLES
The following environment variables are supported:
PKG_TRANS_ID Identifier to use for this transaction.
If undefined (and no alternative means
of specifying a transaction is given),
subcommands requiring transaction
context will fail.
ACTIONS
Each resource within a package must be associated with an action.
See pkg(5) for a complete list of actions.
If an action has an associated payload, the path to the payload
must be the first argument after the action name. (At present, the
file and license actions have payloads.) All other attributes are
specified as a list of name-value pairs, and may be given in any
order. An action must always have a key attribute; however, some
actions may require additional attributes to work correctly.
Arbitrary attributes, beyond those defined for a given action, may
be included in the action. Such attributes are expected to follow
defined conventions such that they carry appropriate meaning or
avoid collision with attributes from other action providers;
specific attributes that cause additional operations, known as
"actuators", are documented in pkg(5).
depend type=<depend_type> fmri=<pkg_fmri> [ property_list ]
Make this package version dependent on the give package FMRI.
Valid depend_types are require and optional.
dir mode=<mode> owner=<userid> group=<groupid> path=<path> \
[ property_list ]
Deliver a directory with the listed attributes into the
transaction.
driver name=<name> perms=<perms> class=<class> alias=<alias> \
[ property_list ]
Deliver driver configuration with the listed attributes into
the transaction. Multiple alias entries may be given to
record multiple device aliases.
file src_path mode=<mode> owner=<userid> group=<groupid> \
path=<path> [ property_list ]
Deliver a file with the listed attributes into the
transaction.
group groupname=<groupname> gid=<gid> [ property_list ]
Deliver a group definition as defined in group(4). If the
group ID, or gid, is omitted, the first free group under 100
will be assigned at installation time. See pkg(5) for
additional details, and relation to the user action below.
hardlink path=<path> target=<target> [ property_list ]
Deliver a link with given path, pointing to the given
target.
legacy category=<category> desc=<description> hotline=<hotline> \
name=<name> pkg=<legacy_pkg> vendor=<vendor> version=<version> \
[ property_list ]
Deliver sufficient metadata, as given by the various fields,
to represent a System V package with name given by legacy_pkg.
license src_path license=<license_name> \
[ property_list ]
Deliver, into the image packaging metadata, the license file
at src_path, labeled by the given license value.
link path=<path> target=<target> [ property_list ]
Deliver a symbolic link with given path, pointing to the given
target.
set name=<name> value=<value> [ property_list ]
Deliver a "package property" defined by the given name and
value.
user username=<username> password=<password> uid=<uid> \
group=<group> gcos-field=<gcos> home-dir=<homedir> \
login-shell=<login-shell> group-list=<group> \
[ group-list=<group> ... ] ftpuser={true|false} \
lastchng=<lastchange> min=<mindays> max=<maxdays> \
warn=<warndays> inactive=<inactivedays> expire=<expiredate> \
flag=<flag> [ property_list ]
Deliver a user account, as defined in passwd(4), shadow(4),
group(4), and ftpusers(4). If the user ID, or uid, is
omitted, then the first free user ID under 100 will be
assigned at installation time. The primary group, specified
by group, must exist prior to the action's execution; this
condition can be ensured by having a group action deliver the
group definition in the same package as the user action, or by
having a depend action that expresses a requirement on a
package possessing a group action. The group-list property
delivers one group to the group(4) entry for the specified
user. Multiple groups are delivered by multiple assignments
to group-list. See pkg(5) for additional details.
EXAMPLES
Example 1: Create a trivial package.
$ eval `pkgsend open example@1.0-1`
$ pkgsend add file example mode=0555 owner=root group=bin \
path=/usr/bin/example
$ pkgsend close
Example 2: Publish a package using filesystem-based publication
and a pre-existing manifest:
$ pkgsend-s file:///tmp/example_repo -d /tmp/pkg_files \
/tmp/pkg_manifest
Example 3: Create a package that delivers two groups and a user.
$ eval `pkgsend open groups-and-user@1.0-1`
$ pkgsend add group groupname=maingrp
$ pkgsend add group groupname=auxgrp
$ pkgsend add user ftpuser=false gcos-field="Example User" \
group=maingrp group-list=auxgrp password=NP username=exuser
$ pkgsend close
EXIT STATUS
The following exit values are returned:
0 Command succeeded.
1 An error occurred.
2 Invalid command line options were specified.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | |
|_____________________________|_____________________________|
SEE ALSOeval(1), pkgrepo(1), pkg.depotd(1M), ftpusers(4), group(4),
passwd(4), shadow(4), attributes(5), pkg(5)NOTES
The image packaging system is an under-development feature.
Command names, invocation, formats, and operations are all subject
to change. Development is hosted in the OpenSolaris community
at:
http://hub.opensolaris.org/bin/view/Project+pkg/
Other package bundle formats can be created. Other forms of package
publication, via the underlying Python API or via the web API, are
also possible.
When publishing individual package files that are greater than 128MB
in size, filesystem-based publication must be used due to publication
protocol limitations. It is also the recommended method of publication
when access control for a repository is needed.
When using filesystem-based publication, any pkg.depot(1M) processes
serving the target repository must be restarted after publication is
completed for the changes to be reflected in its web interface or
search responses. See pkg.depotd(1M) for more information.
