PKGSEND(1) | User Commands | PKGSEND(1) |
pkgsend
— Image
Packaging System publication client
pkgsend |
[options] command [cmd_options] [operands] |
pkgsend |
generate [-T
pattern] [--target
file] source... |
pkgsend |
publish [-b
bundle]... [-d
source]... [-s
repo_uri_or_path] [--key
ssl_key --cert
ssl_cert]... [-T
pattern] [--no-catalog ]
[manifest] ... |
pkgsend
enables the publication of new
packages and new package versions to an image packaging repository using
package manifests. To create or manage repositories, see
pkgrepo(1). To create package
archives from packages in an existing repository, see
pkgrecv(1). For more information
about package manifests, see pkg(7).
After a pkgsend
publish
operation, if your
repo_uri_or_path repository must support
pkg search
operations, run pkgrepo refresh on the repository to
update search indexes.
The following options are supported:
--help
,
-?
The following subcommands are supported:
pkgsend
generate
[-T
pattern]
[--target
file]
sourceRead each source (such as an
SVR4 package, a directory, or a
tar(1) file) and emit the manifest
that describes the source to
stdout
. In the output manifest,
file
and dir
actions
have owner set to
root and group
set to
bin.
The output manifest can then be annotated, have dependencies
added or analyzed using
pkgdepend(1), and have its
correctness verified using
pkglint(1) before being passed to
the publish
subcommand.
If the base name of files in the source match the patterns
specified with -T
, the timestamp of the file is
added to the action for that file. The pattern
uses shell matching rules:
When the specified source is a directory, there is no clear
way to distinguish a file
action from a
hardlink
action when there are multiple path
names for a single inode. Normally, the first one found in the file
system walk is treated as a file and the rest as hardlinks. This can be
arbitrary, depending on the implementation of the file system. To
specify which path names should be treated as files, pass each path name
as an argument to the --target
option. This
option has no effect on other types of sources because they are capable
of expressing which path names are files and which are hardlinks.
When SVR4 packages are provided as a source,
pkgsend
checks that no files with class action
scripts are present and no preinstall, postinstall, preremove, or
postremove scripts are present. An exception is made for any SMF
manifests installed with the
manifest
class.
BASEDIR
is removed from all relocatable paths.
The SVR4 DESC parameter is converted to a pkg.description value. The SVR4 NAME parameter is converted to a pkg.summary value.
pkgsend
publish
[-b
bundle]...
[-d
source]...
[-s
repo_uri_or_path]
[--key
ssl_key
--cert
ssl_cert]...
[-T
pattern]
[--no-catalog
] [manifest]
...Publish a package using the specified package manifests to the
target package repository, retrieving files for the package from the
provided sources. If multiple manifests are specified, they are joined
in the order provided. If a manifest is not specified, the manifest is
read from stdin
.
If not specified, pkgsend
publish
adds the build version to the package
FMRI. The publish
tool also adds the timestamp
(the current time in UTC) to the package FMRI. See the
pkg(7) man page for information about
the version string of a package FMRI.
If multiple pkgsend
publish
processes might be publishing to the
same -s
repository simultaneously, specifying
the --no-catalog
option is recommended. See the
description of the --no-catalog
option
below.
-b
bundle-b
and -d
are
specified, -d
sources are searched first. For
a description of supported bundles and how they are used, refer to the
generate
subcommand above.-d
sourcegenerate
subcommand
above.-s
repo_uri_or_path--key
ssl_key --cert
ssl_cert--key
option to specify a client SSL
key file to use for package retrieval from an HTTPS repository. Use
the --cert
option to specify a client SSL
certificate file to use for package retrieval from an HTTPS
repository. This option pair can be specified multiple times.--no-catalog
-T
option, see the
generate
subcommand above.The following environment variable is supported:
PKG_REPO
The following exit values are returned:
Example 1 Generate and Publish a Package
Create a package using pkgsend
generate
and publish it.
pkgsend generate /path/to/proto > /path/to/manifests/foo.p5m
Add the package FMRI for the example.com publisher to the beginning of foo.p5m.
set name=pkg.fmri value=pkg://example.com/foo@1.0
The resulting manifest should look like this:
set name=pkg.fmri value=pkg://example.com/foo@1.0 dir group=sys mode=0755 owner=root path=usr dir group=bin mode=0755 owner=root path=usr/bin file usr/bin/foo group=bin mode=0555 owner=root path=usr/bin/foo
pkgsend publish -s http://example.com:10000 -d /path/to/proto \ /path/to/manifests/foo.p5m
Example 2 Create and Publish a Trivial Package
Create a manifest for publisher example.com containing the following lines:
set name=pkg.fmri value=pkg://example.com/foo@1.0-1 file /exdir/foo mode=0555 owner=root group=bin path=/usr/bin/foo
Publish the package:
pkgsend publish -s http://example.com:10000 -d /exdir
Example 3 Use a Preexisting Manifest
Publish a package using file system based publication and a preexisting manifest.
pkgsend publish -s /tmp/example_repo -d /tmp/pkg_files \ /tmp/pkg_manifest
The command line interface of pkgsend
is
Uncommitted.
The output of pkgsend
is
Not-An-Interface
and may change at any time.
Because of publication protocol limitations, file system based publication must be used when publishing individual package files that are greater than 128 MiB in size. File system based publication is also recommended when access control for a repository is needed.
When using file system based publication, any pkg.depotd processes that are 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(8).
February 17, 2022 | OmniOS |