User Commandspkgdepend(1)NAMEpkgdepend - image packaging system dependency analyzer
SYNOPSIS
/usr/bin/pkgdepend [options] command [cmd_options] [operands]
/usr/bin/pkgdepend generate [-IMm] -d dir [...] [-D name=value]
[-k path] manifest_path
/usr/bin/pkgdepend resolve [-dmosSv] manifest_path ...
DESCRIPTIONpkgdepend(1) is used to generate and resolve dependencies for
packages. A package may depend upon files from other packages.
pkgdepend(1) is typically used in two passes: file dependency
generation and file-to-package resolution.
The generate subcommand examines a package's content and discovers
what external files the package needs.
The resolve subcommand takes the list of files from the generate
step, and figures out the name of the packages, limited to some
reference set of packages, that contain the dependent files.
Currently, the reference set of packages is defined as the packages
currently installed on the publisher's system.
Several aspects of delivered files are used as sources of
dependency information:
ELF ELF headers in delivered files are analyzed for
dependency information, with the -k and -D options
modifying the information obtained. For more
details on ELF dependencies, please see ldd(1)
and the Solaris Linker and Libraries Guide.
Scripts Shell scripts that contain '#!' lines referencing
an interpreter will result in a dependency on the
package that delivers that interpreter.
Python Python scripts are first analyzed as scripts. In
addition, any imports the script declares may also
serve as sources of dependency information.
Hard links Hard links in manifests will result in a
dependency on the package that delivers the link
target.
SMF SMF service manifests delivered that include
"require_all" dependencies will result in
dependencies on the packages that deliver the SMF
manifests that provide those FMRIs.
OPTIONS
The following options are supported:
-R dir
Operate on the image rooted at dir, rather than the one
discovered automatically.
--help or -?
Displays a usage message.
SUBCOMMANDS
The following subcommands are supported:
generate [-IMm] -d dir [-d dir] [-D name=value] [-k path] manifest_path
Produce the dependencies on files of the manifest specified by
manifest_path.
With -I, the dependencies which are satisfied within the
manifest given will be shown.
With -M, a list of those file types which could not be
analyzed will be displayed.
With -m, the original manifest will be repeated with any
discovered dependencies added after.
With -d, add the directory provided to a list of directories
to search for the manifest's files.
For each -D, add the 'value' as a way to expand the token
'name' in run paths for elf file dependencies.
For each -k, add the path given to the list of paths in which
to look for kernel modules. Using the -k argument removes the
default paths which are /kernel and /usr/kernel.
resolve [-mov] [-d output_dir] [-s suffix] manifest_path ...
Transform dependencies on files into dependencies on the
packages which deliver those files. Dependencies are first
resolved against the manifests given on the command line and
then against the packages installed on the system. By
default, the dependencies for each manifest are placed in a
file whose name is determined by appending ".res" to the
manifest's path.
With -m, repeat the manifest, with any dependencies produced
by the generate step removed, before adding the resolved
dependencies.
With -o, write the results to standard output.
With -d, write the resolved dependencies for each manifest
provided in a separate file in output_dir. By default, each
file will have the same basename as the manifest that was the
source of the dependencies written to that file.
With -s, for each output file, append the given suffix (a "."
will be added to the argument if not provided) to the basename
of the file that was the source of the resolved dependencies.
With -S, only resolve against the manifests given on the command
line and not against those installed on the system.
With -v, include additional package dependency debugging
metadata.
EXAMPLES
Example 1: Generate the dependencies for the manifest written in
foo, whose content directory is in ./bar/baz and store the results
in foo.fdeps.
$ pkgdepend generate foo ./bar/baz > foo.fdeps
Example 2: Resolve the file dependencies in foo.fdeps, and
bar.fdeps against each other, and the packages currently installed
on the system.
$ pkgdepend resolve foo.fdeps bar.fdeps
$ ls *.res foo.fdeps.res bar.fdeps.res
Example 3: Generate the file dependencies for two manifests (foo
and bar) and retain all the information in the original manifests.
Then resolve the file dependencies and place the resulting
manifests, which could be used with pkgsend publish, in ./res
$ pkgdepend generate -m foo > ./deps/foo
$ pkgdepend generate -m bar > ./deps/bar
$ pkgdepend resolve -m -d ./res ./deps/foo ./deps/bar
$ ls ./res foo bar
Example 4: Replace all $PLATFORM tokens in the run paths in elf
files with sun4v and sun4u while generating the dependences for the
manifest written in foo whose content directory is in /.
$ pkgdepend generate -D 'PLATFORM=sun4v' -D 'PLATFORM=sun4u' foo /
Example 5: Use /kmod as the directory in which to find kernel
modules when generating the dependencies for the manifest written
in foo whose content directory is in /.
$ pkgdepend generate -k /kmod foo /
EXIT STATUS
The following exit values are returned:
0 Everything worked.
1 Something bad happened.
2 Invalid command line options were specified.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWipkg |
| | pkg:/package/pkg |
|_____________________________|_____________________________|
| Interface Stability | None / Under Development |
|_____________________________|_____________________________|
SEE ALSOattributes(5), pkg(5)
