PKG_CREATE(1) | General Commands Manual | PKG_CREATE(1) |
pkg_create
—
create binary software package for distribution
pkg_create |
[-mnQqvx ]
[-A arches]
[-B pkg-destdir]
[-D name[=value]]
[-L localbase]
[-M displayfile]
[-P pkgpath:pkgspec:default]
[-U undisplayfile]
[-u userlist]
[-V n]
[-W libspec] -d
desc -D
COMMENT=value -D
PORTSDIR=value -f
packinglist -p
prefix pkg-name |
pkg_create |
-f packinglist |
The pkg_create
command is normally used to
create a binary package named pkg-name, for subsequent
use with pkg_add(1),
pkg_delete(1) and
pkg_info(1).
pkg-name will traditionally have a
“.tgz” extension, to denote the underlying binary format.
pkg-name must follow
packages-specs(7).
Use of the ports(7)
infrastructure instead of manual pkg_create
invocation is strongly recommended.
pkg_create
can also be used to recreate a
binary package from an existing installation.
During package creation, pkg_create
replaces too long file names with smaller equivalents (see
package(5)), records extra
information in the packing-list, such as the existence of symlinks and hard
links, computes and stores file checksums, and verifies that all special
objects are properly annotated in the packing-list.
It will also check all required shared libraries for reachability,
by looking into all installed dependencies. It may also ask the ports tree
for extra dependencies, provided some other dependency refers to the same
BASE_PKGPATH
(see
bsd.port.mk(5)). The
rationale is that those libraries must already be present for the package to
build correctly, and thus be reachable through the subset of dependencies
that are not pure RUN_DEPENDS
.
The options are as follows:
-A
arches-B
pkg-destdir-D
name[=value]CDROM
COMMENT
HISTORY_DIR
FTP
FULLPKGPATH
HOMEPAGE
MAINTAINER
USE_GROFF
-d
[-
]desc-f
packinglist-L
localbase-M
displayfile-m
pkg_create
to always display the progress
meter in cases it would not do so by default.-n
-P
pkgpath:pkgspec:default-p
prefix-Q
@file
,
@lib
, ...
).-q
-n
.-U
undisplayfile-u
userlist@newuser
and
@newgroup
statements against a
userlist file (usually
${PORTSDIR}/infrastructure/db/user.list) and error
out for entries not registered in that file. Also error out if the file is
incoherent.-V
n@version
have an implicit version of 0.-v
-W
libspec-x
pkg_create
can also be invoked with only
the packing-list from an installed package. It will recreate the
corresponding binary package in the current directory from the installation,
or error out if any problem is found. For example, the following will
recreate a kdelibs-3.4.3.tgz package:
pkg_create -f /var/db/pkg/kdelibs-3.4.3/+CONTENTS
The “packing-list” format (see
-f
) is fairly simple, being basically a list of
filenames and directory names to include in the package.
Substitution of variables and inclusion of fragments is documented in the next section.
Directory names are denoted by a trailing slash.
There are some annotations that can be inserted for better control. All these commands start with an ‘@’. The following annotations can be inserted manually (but commonly update-plist(1) is used for creating most packing-list contents):
@ask-update
pkgspec message-D
update_stem, with
stem the stem of the pkgspec.
Classical use case for postgresql:
@ask-update postgresql-server-<8 Make sure your existing database is backed up
Use very sparingly. Most cases that seem to require manual updates just require a bit more thought.
@bin
filename@comment
stringThe special comment @comment no
checksum
can be used to tag the next file as special: even though
its characteristics will be recorded in the package, it can be altered
after installation, and
pkg_delete(1) will
still delete it.
The special comment @comment no debug
can be used to tag the next file as special: even though it might be a
binary, it has no debug info (see
build-debug-info(1)).
@conflict
pkgspec@cwd
pathname@dir
directoryname@mode
, @group
, and
@owner
into account, and remove it during
pkg_delete(1).
Directories to remove can be shared between packages. If
name does not begin with an @, same as
name/
@define-tag
tag mode params@exec
commands.
The %D
escape sequence stands for
localbase.
Actual tags may themselves contain parameters, so the params list recognizes two additional escape sequences:
%l
%u
As a special case, deleting the package that contains the
@define-tag
will work differently: If that
@tag
is present in the same package as the
@define-tag
, then it will be run when
encountered, presumably before the command itself has been deleted.
If that @tag
is not present, the command
won't be run at all, since the package has been deleted from the
file system, and usually cleaning up only requires removing index
files.
@define-tag mktexlsr at-end mktexlsr @define-tag mktexlsr-local at-end mktexlsr texmf-local @define-tag mktexlsr supersedes mktexlsr-local
Here, the tag mktexlsr rebuilds every texmf directory index, whereas mktexlsr-local only rebuilds the local texmf directory index, so if both tags are seen, only the global command will be run.
@exec
command@exec
commands are executed relative to their
location in the packing-list, so they can rely on any data that have
already been extracted, but not on anything that is listed after them.
Some special elements, such as new users and new groups, are always
created first, so that @exec
can rely on them.
pkg_add(1) and
pkg_delete(1) set the
PATH
to a predictable value:
/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:${LOCALBASE}/bin:${LOCALBASE}/sbin
during execution.
If command contains any of the following
sequences somewhere in it, they will be expanded inline. For the
following examples, assume that @cwd
is set to
/usr/local and the last extracted file was
bin/emacs.
%B
%D
@cwd
; in the example case
/usr/local.%F
%f
%B
; in the example
case, emacs.@exec-always
command@exec
.
@exec-add
command@exec
, except it only gets executed
during new installations, and not during updates.
@exec-update
command@exec
, except it only gets executed
during updates, and not during new installations.
@extra
filename-c
option. Those
files are extra configuration files that are normally not deleted.
filename can be an absolute path. If
filename ends with a slash, it is a directory.
@extraunexec
command@file
filename@cwd
.
@fontdir
directoryname@dir
, to handle font
directories: create font.alias from
font.alias-* fragments, execute
mkfontdir(1),
mkfontscale(1) and
fc-cache(1) when needed.
Delete extra files at
pkg_delete(1) time.
@group
group@info
filename@file
, to handle GNU info
files. Automatically grab filename-* chapter files,
run install-info(1)
as needed.
@lib
filename@file
, to handle shared
libraries. Satisfy LIB_DEPENDS and WANTLIB, run
ldconfig(8) as needed.
See ‘VARIABLE SUBSTITUTION AND FRAGMENT INCLUSION’ for some
details.
@man
filename@file
, to handle manual
pages.
@mandir
directoryname@dir
, to handle manual
directories: instruct user to add/remove the directory to
man.conf(5), remove
apropos(1) database when
needed.
@mode
mode@newgroup
name:gid@newuser
name:uid:group:loginclass:comment:home:shell@newuser foo:!42
will make sure user foo
has UID 42. During
pkg_delete(1), users
will be deleted if extra clean-up has been requested, and if other
installed packages don't list the same user.
@option
namealways-update
is-branch
no-default-conflict
@owner
user@pkgpath
pkgpathpkg_add
-u
normally checks that the
pkgpath embedded in the package corresponds to the
old package, to solve ambiguities when packages with similar names are
involved. When ports get renamed, or flavors change, extra
@pkgpath
annotations can help
pkg_add
get a sense of continuity. Note that these
pkgpath can take extra optional components, to allow
the matching of several flavors at once, and are order independent. For
instance,
@pkgpath some/dir,f1,f2
and
@pkgpath some/dir,f2,f2,f1
are equivalent.
@pkgpath some/dir,f1[,f2,f3][,f4]
will match all pkgpaths to some/dir with flavor f1, and optionally f4, and optionally both f2 and f3, e.g., some/dir,f1,f4, some/dir,f1,f2,f3, some/dir,f1,f2,f3,f4, some/dir,f1 would match, but some/dir,f1,f5, some/dir,f2,f3, some/dir,f1,f2,f4 would not.
Each binary package contains a set of pkgpaths: the primary
pkgpath that was used to build the package, recorded as
@comment
pkgpath=some/path, and secondary pkgpaths as
recorded through @pkgpath
.
In order for two packages to match, their primary pkgpaths must match, or a secondary pkgpath must match the other package's primary pkgpath.
@rcscript
filename@file
, absolute paths are okay, e.g.,
@rcscript ${RCDIR}/ballsd
In this case, performs an implicit
@cwd
to ${RCDIR}.
@sample
filename@file
item is a sample
configuration file, to be copied to filename at
pkg_add(1) time and to be
removed at
pkg_delete(1) time.
During installation, existing configuration files are untouched. During
deinstallation, configuration files are only removed if unchanged.
filename can be an absolute path. If
filename ends with a slash, it refers to a
configuration directory instead.
@shell
filename@file
, to handle shells.
See shells(5).
@so
filename@static-lib
filename@unexec
commandPATH
and expansion of special
%
sequences are the same as for
@exec
. Note that @unexec
commands are executed relative to their location in the packing-list, so
they cannot rely on any data that has already been deleted, thus they
should occur before the files they need to function. Some special
elements, such as new users and new groups, are always deleted last, so
that @unexec
can rely on them.
@tag
name [parameter]@define-tag
definition must be accessible through
the dependency tree. parameter is amenable to the
same substitutions as @exec
.
@unexec-always
command@unexec
.
@unexec-delete
command@unexec
, except it only gets executed
during true deletions and not while removing an old package during
updates.
@unexec-update
command@unexec
, except it only gets executed
while removing an old package during updates, and not during true
deletions.The @bin
, @lib
,
@so
and @static-lib
annotations are used by the debug packages infrastructure to figure out
which files may contain debug information.
See package(5) for other internal annotations that are automatically added by the package tools.
In packing-lists, installation, deinstallation and requirement
scripts, description and message files, constructs like
${VAR}
will be replaced with the variable value,
according to -D
name=value options.
In particular, shared library versions should never be mentioned
explicitly in a packing-list. Shared library ‘foo’ will take
its version number from LIBfoo_VERSION
. The ports
framework normally takes care of all details, see
SHARED_LIBS
in
bsd.port.mk(5).
Constructs like %%VAR%%
and
!%%VAR%%
trigger fragment inclusion. If such a line
is encountered in a packing-list, the corresponding variable must be defined
to 0 or 1. If the variable's value is 1, %%VAR%%
will be replaced by the corresponding positive fragment, and
!%%VAR%%
will be ignored. If the variable's value is
0, %%VAR%%
will be ignored, and
!%%VAR%%
will be replaced by the corresponding
positive fragment.
A fragment is an auxiliary packing-list file, whose name is derived from the current packing-list, and the variable name VAR triggering the inclusion: pkg/PLIST yields a positive fragment pkg/PFRAG.VAR and a negative fragment pkg/PFRAG.no-VAR, pkg/PLIST-FOO yields a positive fragment pkg/PFRAG.VAR-foo and a negative fragment pkg/PFRAG.no-VAR-foo.
Fragments can be included inside fragments, so that
%%VAR2%%
inside
pkg/PFRAG.VAR triggers the inclusion of
pkg/PFRAG.VAR2-VAR and
!%%VAR2%%
triggers the inclusion of
pkg/PFRAG.no-VAR2-VAR.
If a positive or a negative fragment file does not exist, the
corresponding inclusion will be ignored. However, if both the positive and
negative fragment files do not exist, pkg_create
will error out, to make it easier to spot fragment names errors.
pkg_add(1), pkg_delete(1), pkg_info(1), pkg_sign(1), tar(1), bsd.port.mk(5), package(5), packages-specs(7), pkgpath(7), ports(7)
The pkg_create
command first appeared in
FreeBSD.
April 23, 2020 | OpenBSD-6.7 |