NAME
pkg_create
—
create binary software package for
distribution
SYNOPSIS
pkg_create |
[-mnQqSvx ]
[-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
FULLPKGPATH=value -D
PORTSDIR=value -f
packinglist -p
prefix pkg-name |
pkg_create |
-f packinglist |
DESCRIPTION
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- Register a list of architectures for which this package should install. arches is a comma-separated list of architectures. Use ‘*’ to mean any architecture (e.g., arch-independent packages).
-B
pkg-destdir- Set pkg-destdir as the prefix to prepend to any file to select for the package.
-D
name[=value]- Define name to value (or just
define it) for substitution and fragment inclusion purposes. Some specific
names have extra meaning, see
bsd.port.mk(5) and
package(5) for details:
CDROM
- Set to the port's Makefile PERMIT_PACKAGE_CDROM.
COMMENT
- Set package “one line description” (mandatory).
HISTORY_DIR
- Record checksums of files in permanent location ${HISTORY_DIR}/${FULLPKGPATH:S,/,./g}.lru.
FTP
- Set to the port's Makefile PERMIT_PACKAGE_FTP.
FULLPKGPATH
- Location in the ports tree, mandatory for updates to work (see pkg_add(1)).
HOMEPAGE
- If defined, appended to the description.
MAINTAINER
- If defined, appended to the description.
NO_TS_IN_PLIST
- If set, disable the
@ts
annotations in the generated package, rely on the normal tar(1) timestamps instead. (Mostly used to create firmware "packages" since fw_update(8) only handles a very small subset of the package(5) format.) USE_GROFF
- Set to 1 to have groff format manpages behind the scenes during package creation.
REVISION_CHECK
,EPOCH_CHECK
,FLAVOR_LIST_CHECK
- Set automatically by bsd.port.mk(5) to values that help
pkg_create
catch a few errors in package naming.
-d
[-
]desc- Fetch long description for package from file desc or, if preceded by ‘-’, the argument itself.
-f
packinglist- Fetch “packing-list” for package from the file packinglist. Several packing-lists can be mentioned, in which case they will be concatenated together.
-L
localbase- Record localbase as the localbase used in the package (By default, /usr/local). Packages built with another localbase can only be installed by using the same localbase in pkg_add(1), to prevent errors.
-M
displayfile- Display the file (using more(1)) after installing the package. Useful for things like legal notices on almost-free software, etc.
-m
- Causes
pkg_create
to always display the progress meter in cases it would not do so by default. -n
- Don't actually create a package.
-P
pkgpath:pkgspec:default- Declare a dependency on a package matching pkgspec
(see packages-specs(7)). An appropriate package must be installed before
this package may be installed, and that package must be deinstalled before
this package is deinstalled. The dependency also contains a
pkgpath (see pkgpath(7)) and a default package
name, in case there is no listing of available packages.
As a special case, ‘=’ may be used as a pkgspec, to match the default version exactly.
-p
prefix- Set prefix as the initial directory “base” to start from in selecting files for the package, and to record as the base for installing the package.
-Q
- Print out the files in the actual packing-list of the package being
generated, with explicit typing (e.g.
@file
,@lib
,...
). -q
- Print out the actual packing-list of the package being generated (query
mode). Most often used in combination with
-n
. -S
- Print the update signature of the package. See pkg_info(1).
-U
undisplayfile- Display the file (using more(1)) when deinstalling the package. Useful for reminders about stuff to clean up.
-u
userlist- Check all
@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- Adds n to the ‘global system version’
of the package (see package(5)). The default value of 0 is not recorded, thus packages
without
@version
have an implicit version of 0. -v
- Turn on verbose output.
-W
libspec- Package needs a shared library to work. libspec is ‘name.major.minor’ or ‘path/name.major.minor’. The package won't be installed unless a library with the same name, the exact same major number and at least the same minor number can be located. A library without path is searched through dependent packages under the same localbase, then in the system libraries under /usr/lib and /usr/X11R6/lib. A library with a path is only searched through dependent packages, that path being relative to localbase.
-x
- Disable progress meter.
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
PACKING-LIST DETAILS
The “packing-list” format (see
-f
) is fairly straightforward: 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- Mechanism to prevent unwanted updates. If the new package is installed as
part of an update matching pkgspec, the
message will be displayed to the user. In
non-interactive mode, the update will abort. Otherwise, the user will have
a chance to proceed. Automated updates can be done by using
-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- Describe the file as an OpenBSD binary executable (not a script).
@comment
string- Place a comment in the packing-list. Useful in trying to document some
particularly hairy sequence that may trip someone up later. Can also be
used to comment out elements that update-plist (see
bsd.port.mk(5)) will
insist in inserting in a packing-list.
The 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- Declare a conflict with packages matching pkgspec (see packages-specs(7)). The pkgname package can not be installed if a package matching pkgspec has been installed because they install the same files and thus conflict.
@cwd
pathname- Set the package current directory. All subsequent filenames will be assumed relative to pathname.
@dir
directoryname- Create directory directoryname at
pkg_add(1) time, taking
@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 asname/
@define-tag
tag mode params- Define a tag of name tag. Tags define actions to be
performed at specific time during pkg_add(1) and pkg_delete(1). A given tag may be defined several times
with additional properties. Currently, the following modes are defined:
- at-end
- if the tag occurs in any dependency, the given command
params is executed at the end, similar to
@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
- list of tag parameters, in a random order, with duplicates removed.
%u
- execute the command once for each distinct tag parameter.
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. - supersedes
- If the given tag is found in dependencies, it supersedes the other tag
given in the same line. For instance:
@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- Execute command during
pkg_add(1). Note that
@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
- Expands to the “basename” of the fully qualified filename, that is the current directory prefix, plus the last filespec, minus the trailing filename. In the example case, that would be /usr/local/bin.
%D
- Expands to the current directory prefix, as set with
@cwd
; in the example case /usr/local. %F
- Expands to the last filename extracted (as specified); in the example case, bin/emacs.
%f
- Expands to the “filename” part of the fully qualified
name, or the converse of
%B
; in the example case, emacs.
@exec-always
command- Synonym of
@exec
. @exec-add
command- Similar to
@exec
, except it only gets executed during new installations, and not during updates. @exec-update
command- Similar to
@exec
, except it only gets executed during updates, and not during new installations. @extra
filename- Declare extra file filename to be deleted at
deinstall time, if user sets the
-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- Extra command to execute when removing extra files.
@file
filename- Default annotation, to use if filename begins with
@. filename is always a relative path, relative to
the current
@cwd
. @fontdir
directoryname- Specialized version of
@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- Set default group ownership for all subsequently extracted files to group. Use without an arg to set back to default (extraction) group ownership.
@info
filename- Specialized version of
@file
, to handle GNU info files. Automatically grab filename-* chapter files, run install-info(1) as needed. @lib
filename- Specialized version of
@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- Specialized version of
@file
, to handle manual pages. @mandir
directoryname- Specialized version of
@dir
, to handle manual directories: instruct user to add/remove the directory to man.conf(5), remove apropos(1) database when needed. @mode
mode- Set default permission for all subsequently extracted files to mode. Format is the same as that used by the chmod(1) command. Use without an arg to set back to default (extraction) permissions.
@newgroup
name:gid- During pkg_add(1), create a new group, using groupadd(8). Happens before file and user creations. gid can be prefixed with a ‘!’ to ensure group has the correct GID. During pkg_delete(1), groups will be deleted if extra clean-up has been requested, and if other installed packages don't list the same group.
@newuser
name:uid:group:loginclass:comment:home:shell- During pkg_add(1),
create a new user. Happens before any file creation. All fields correspond
to useradd(8)
parameters. Some fields are optional and can be left empty. If the user
already exists, no action is taken. Individual fields can be prefixed by a
‘!’ to make sure an existing user matches. For instance, the
directive
@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- Effects vary depending on name. These are the user
settable options
always-update
- By default, pkg_add(1) uses some simplified information to decide whether
an installed package needs updating. With this option, the package
will be updated whenever anything changes.
This is meant to be used by packages containing information relating to the whole ports tree, like sqlports, quirks, pkglocatedb.
is-branch
- Annotate the few rare ports where several branches are present in the ports tree (such as autoconf), to help pkg_info(1) produce stem%branch annotations when needed.
no-default-conflict
- By default, a package conflicts with other versions of the same package. With this option, the older package version will still be noticed, but the installation will proceed anyway.
@owner
user- Set default ownership for all subsequently extracted files to user. Use without an arg to set back to default (extraction) ownership.
@pkgpath
pkgpath- Declare a secondary pkgpath for the package. This is
used for updates:
pkg_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 helppkg_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- Script for the /etc/rc.d framework. Contrary to
@file
, absolute paths are okay, e.g.,@rcscript ${RCDIR}/ballsd
In this case, performs an implicit
@cwd
to ${RCDIR}. @sample
filename- Last preceding
@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- Specialized version of
@file
, to handle shells. See shells(5). @so
filename- Describe the file as an OpenBSD shared object.
@static-lib
filename- Describe the file as a OpenBSD static library.
@unexec
command- Execute command during
pkg_delete(1).
PATH
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]- Reference a tag of given name. The corresponding
@define-tag
definition must be accessible through the dependency tree. parameter is amenable to the same substitutions as@exec
. @unexec-always
command- Synonym of
@unexec
. @unexec-delete
command- Similar to
@unexec
, except it only gets executed during true deletions and not while removing an old package during updates. @unexec-update
command- Similar to
@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.
Some of these annotations define information that are local to
each port but global to the package ecosystem in general, and thus make it
into the package locate database by default (for instance:
@define-tag
, @newuser
and
@newgroup
). See
pkg_mklocatedb(1)
for details.
See package(5) for other internal annotations that are automatically added by the package tools.
VARIABLE SUBSTITUTION AND FRAGMENT INCLUSION
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.
SEE ALSO
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)
HISTORY
The pkg_create
command first appeared in
FreeBSD.
AUTHORS
- Jordan Hubbard
- initial design
-
Marc Espie - complete rewrite.