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 pkg-dependency]
[-s signature-parameter]
[-U undisplayfile]
[-W wantedlib] -d
desc -D
COMMENT=value -D
PORTSDIR=value -f
packinglist -p
prefix pkg-name |
pkg_create |
[-s signature-parameter]
-f packinglist |
The pkg_create
command creates 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.
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 @wantlib
for
reachability, by looking into all installed @depend
.
It may also ask the ports tree for extra dependencies, provided some other
@depend
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
@depend
that are not pure
RUN_DEPENDS
.
The options are as follows:
-A
arches-B
pkg-destdir-D
name[=value]-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
pkg-dependency@depend
dependency on the command
line.-p
prefix-Q
@file
,
@lib
, ...
).-q
-n
.-s
x509 -s
cert -s
privkey-s
options:
x509 to indicate X.509-style signatures,
cert the path to the signer's certificate and
privkey the path to the signer's private key. The
signer's certificate and the signer's private key should be generated
using standard openssl x509 commands. This assumes the existence of a
certificate authority (or several), whose public information is recorded
as a /etc/ssl/pkgca.pem file.-U
undisplayfile-v
-W
wantedlib@wantlib
requirement on the command
line.-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 a few annotations that can be inserted for better control. All these commands start with an ‘@’. Here is a list:
@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.
@arch
arches@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.
@conflict
pkgspec@cwd
pathname@depend
pkgpath:pkgspec:default@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/
@display
name-M
above).
@endfake
-Q
option.
@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. 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@ignore
@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.
@link
namepkg_create
to record
that the entry is actually a hard link.
@localbase
base-L
option.
@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.
@md5
pkg_create
to record
the files's cryptographic checksum. Replaced by
@sha
since OpenBSD 4.5.
@mode
mode@name
pkgnamepkg_create
will derive this field from the package name and add it automatically if
none is given.
@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
name@owner
user@pkgcfl
pkgcflname@conflict
instead.
@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.
@sha
pkg_create
to record
the files's cryptographic checksum, as a sha256 digest encoded in base64.
@shell
filename@file
, to handle shells.
See shells(5).
@size
pkg_create
to record a
file size.
@symlink
namepkg_create
to record
that the entry is actually a symbolic link.
@sysctl
var=val@sysctl
var≥val@unexec
command%
sequences is 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.
@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.
@url
@wantlib
libspecIn 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), not to
be confused with SHARED_LIBS later in this
document.
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.
Shared libraries no longer require any fragments, but can be
included directly in the final packing-list: on an architecture without
shared libraries, @lib
lib/libfoo.so.${LIBfoo_VERSION}
will automatically devolve into
lib/libfoo.a
, if needed (e.g., for a port that
builds both a shared library and a normal library on a shared libraries
architecture, @lib lib/libfoo.so.${LIBfoo_VERSION}
will simply vanish on non-shared architectures). Extra copies living in
other directories will be ignored (See the description of
SHARED_ONLY
and
NO_SHARED_LIBS
in
bsd.port.mk(5)).
As a special historical exception, the variable
SHARED_LIBS still control the inclusion of fragments
PFRAG.shared and
PFRAG.no-shared through the lines
%%SHARED%%
and
!%%SHARED%%
.
PKG_DESTDIR
-B
option is specified.openssl(1), pkg_add(1), pkg_delete(1), pkg_info(1), tar(1), bsd.port.mk(5), package(5), pkg.conf(5), packages-specs(7), pkgpath(7), ports(7)
The pkg_create
command first appeared in
FreeBSD.
June 8, 2012 | OpenBSD-5.4 |