bpkg-pkg-build(1) General Commands Manual bpkg-pkg-build(1) NAME bpkg-pkg-build - build package SYNOPSIS bpkg pkg-build|build [options] [--upgrade|-u | --patch|-p] [cfg-var... --] pkg-spec... bpkg pkg-build|build [options] --upgrade|-u | --patch|-p [cfg-var... --] pkg-spec = [flags](([scheme:]pkg[ver-spec]),...[@rep-loc] | [@]rep-loc | file | dir/) flags = ? scheme = sys ver-spec = /version | version-constraint DESCRIPTION The pkg-build command builds one or more packages including all their de- pendencies. Besides building new packages, this command is also used to up- grade or downgrade packages that are already present in the configuration. And unless the --keep-unused|-K option is specified, pkg-build will also drop dependency packages that would otherwise no longer be used. The first form (one or more packages are specified) builds new or upgrades (by default or if --upgrade is specified) or patches (if --patch is speci- fied) the specified packages. The second form (no arguments but either --upgrade or --patch is specified) upgrades or patches all the held pack- ages in the configuration (see below for details on held package). In both forms specifying the --immediate|-i or --recursive|-r option causes pkg-build to also upgrade or patch the immediate or all dependencies of the specified (first form) or held (second form) packages, respectively. Note also that in the first form these options can only be specified with an ex- plicit --upgrade or --patch. Each package can be specified as just the name (pkg) with optional version specification (ver-spec), in which case the source code for the package will be automatically fetched from one of the configured repositories. See the bpkg-rep-add(1) and bpkg-rep-fetch(1) commands for more information on package repositories. The version specification (ver-spec) can be either the exact version in the /version form or the version constraint as de- scribed in Package Version Constraint (#package-version-constraint). If ver-spec is not specified, then the latest available version will be built. To downgrade, the desired version must be specified explicitly. For exam- ple: bpkg build foo libfoo/1.2.3 "bar < 2.0.0" Alternatively, the package repository location (rep-loc) can be specified as part of the build command. In this case, if ver-spec is not specified, then the latest available from this repository version will be built. For example: bpkg build foo,libfoo/1.2.3@https://git.example.org/foo.git#master If only the location is specified, then the latest versions of all the packages available directly from this repository will be built (note that this does not include packages available from complement repositories). The @ delimiter can be omitted if the location is a URL. For example: bpkg build https://git.example.org/foo.git#master bpkg build @/path/to/repository/ A package name (pkg) can be prefixed with a package scheme (scheme). Cur- rently the only recognized scheme is sys which instructs pkg-build to con- figure the package as available from the system rather than building it from source. The system package version (ver-spec) may not be a version constraint but may be the special '/*' value, which indicates that the version should be considered unknown but satisfying any version constraint. If unspecified, then pkg-build will attempt to query the system package manager for the in- stalled version unless the system package manager is unsupported or this functionality is disabled with --sys-no-query, in which case the '/*' ver- spec is assumed. If the system package manager is supported, then the auto- matic installation of an available package can be requested with the --sys- install option. Note that if the version is not explicitly specified, then at least a stub package must be available from one of the repositories un- less the --sys-no-stub option is specified. Finally, a package can be specified as either the path to the package archive (file) or to the package directory (dir/; note that it must end with a directory separator). See the bpkg-pkg-fetch(1) and bpkg-pkg-un- pack(1) commands for more information on the semantics of specifying the package as an archive or a directory. Additional configuration variables (cfg-var), if any, should be specified before packages (pkg-spec) and should be separated with --. Such variables are effective only when configuring and only for packages that were explic- itly specified on the command line (unless global overrides). They can also be specified to only apply to specific packages using the argument grouping mechanism discussed below. See bpkg-pkg-configure(1) for more information on configuration variables. By default a package that is specified explicitly on the command line is built to hold: it will not be considered for automatic removal if it no longer has any dependents. Only versions from repositories that were added to the configuration (bpkg-rep-add(1)) are considered as available for build to hold. Alternatively, a package can be built (or, more commonly, upgraded/down- graded) as a dependency by specifying the ? flag (flags) or the --depen- dency option. Such a package will only be added to the configuration if it actually has any dependents and once no longer used, it will be automati- cally dropped. Only versions from prerequisite repositories of dependent packages are considered as available for build as a dependency. Packages (both built to hold and as dependencies) that are specified with an explicit package version (ver-spec) or as an archive or directory, will have their versions held, that is, they will not be automatically upgraded. As an illustration, let's assume in the following example that the stable repository contains packages foo 1.0.0 as well as libfoo 1.0.0 and 1.1.0 while testing - libfoo 2.0.0, that testing is complemented by stable, and that foo depends on libfoo >= 1.0.0: bpkg fetch https://example.org/1/testing bpkg build foo # build foo 1.0.0 to hold # build libfoo 1.1.0 as dependency bpkg build ?libfoo/1.0.0 # downgrade libfoo 1.0.0 as dependency, # also hold version 1.0.0 bpkg build ?libfoo/2.0.0 # error: 2.0.0 unavailable in dependent's # (foo) repository (stable) bpkg build libfoo/2.0.0 # upgrade libfoo 2.0.0 to hold, # also hold version 2.0.0 A package can be built in one of the linked configurations instead of the current (or host/build system module, for build-time dependencies) configu- ration by specifying one of the --config-* options (see bpkg-cfg-create(1) for background on linked configurations). For example: bpkg build foo { --config-name=alt-host }+ ?bison PKG-BUILD PACKAGE OPTIONS The following options (as well as additional configuration variables) can be grouped to apply to a specific pkg-spec as well as specified globally, in which case they apply to all the specified packages (see bpkg-argument- grouping(1) for details). --upgrade|-u Upgrade packages to the latest available version that satisfies all the constraints. --patch|-p Upgrade packages to the latest available patch version that satis- fies all the constraints. --deorphan Replace orphaned packages with the best matching available package versions which satisfy all the constraints. It may happen that a built package no longer has the corresponding package available in the repository it came from (for example, as a result of bpkg-rep-fetch(1) or bpkg-rep-remove(1)). Such a package is called an orphan. Without the --deorphan option, upgrading, down- grading, or patching an orphan will leave it unchanged if a more suitable version of the package is not available. If the --deorphan option is specified, then an orphan will be replaced with a non-or- phan. In this case, if --upgrade, --patch, or the package version is specified, then the new version is selected accordingly. Otherwise, the closest version to the orphaned version is selected using the following preference order: (1) same version, revision, and itera- tion, (2) latest iteration of same version and revision, (3) later revision of same version, (4) later patch of same version, (5) later minor of same version, (6) latest available version, including ear- lier (see Package Version (#package-version) for details). --immediate|-i Also upgrade, patch, or deorphan immediate dependencies. --recursive|-r Also upgrade, patch, or deorphan all dependencies, recursively. --upgrade-immediate Upgrade immediate dependencies. --patch-immediate Patch immediate dependencies. --deorphan-immediate Deorphan immediate dependencies. --upgrade-recursive Upgrade all dependencies, recursively. --patch-recursive Patch all dependencies, recursively. --deorphan-recursive Deorphan all dependencies, recursively. --dependency Build, upgrade, or downgrade a package as a dependency rather than to hold. --keep-out Keep output directories of external packages between upgrades and downgrades. Refer to bpkg-pkg-disfigure(1) for details. --disfigure Disfigure packages between upgrades and downgrades effectively caus- ing a from-scratch reconfiguration. --checkout-root dir Check out packages that come from version control-based repositories into the specified directory rather than into the configuration di- rectory. Refer to the --output-root option in bpkg-pkg-checkout(1) for details. --checkout-purge Remove the checked out package (source) directories when the pack- ages are purged. Refer to the --output-purge option in bpkg-pkg- checkout(1) for details. --config-name name Name of the linked configuration to build this package(s) in. By de- fault, the package is built in the current configuration. Repeat this option to specify multiple configurations. --config-id num Numeric id of the linked configuration to build this package(s) in. By default, the package is built in the current configuration. Re- peat this option to specify multiple configurations. --config-uuid uuid UUID of the linked configuration to build this package(s) in. By de- fault, the package is built in the current configuration. Repeat this this option to specify multiple configurations. PKG-BUILD GLOBAL OPTIONS --yes|-y Assume the answer to all prompts is yes. Note that this excludes the system package manager prompts; see --sys-yes for details. --for|-f operation Instead of the default update build system operation, perform the update-for-operation variant where operation is normally install or test. --keep-unused|-K Don't drop dependency packages that were automatically built but will no longer be used. --update-dependent|-U Update without confirmation dependent packages that are reconfigured due to their dependencies being upgraded or downgraded. --leave-dependent|-L Don't offer to update dependent packages that are reconfigured due to their dependencies being upgraded or downgraded. --configure-only|-c Configure all the packages but don't update. --print-only Print to stdout what would be done without actually doing anything. --plan header Print the plan (even if --yes is specified) and start it with the header line (unless it is empty). --no-fetch Don't fetch repositories specified as part of the build command. --fetch-shallow Don't re-fetch complement and prerequisite repositories of reposito- ries specified as part of the build command. Refer to the --shallow option in bpkg-rep-fetch(1) for details. --mask-repository rep For the duration of the command execution pretend the specified repository was removed as if by performing the rep-remove command. The repository can be specified either as a repository name or as a repository location (URL or a directory path). Note that the reposi- tory's complement and prerequisite repositories are also considered masked, recursively, unless they are complements and/or prerequi- sites of other unmasked repositories. Repeat this option to mask multiple repositories. --mask-repository-uuid v For the duration of the command execution pretend the specified repository was removed from the specified configuration. Similar to --mask-repository but only masks the repository in a single configu- ration. The option value is a key-value pair in the form: config-uuid=rep Repeat this option to mask multiple repositories. --no-refinement Don't try to refine the configuration by offering to drop any unused dependencies that were potentially left behind on the previous pkg- build or pkg-drop command execution if the command is otherwise a noop (performs no new package builds, upgrades, etc). --no-move Don't move dependency packages between configurations. In this mode the --config-* options specify packages' current rather than new lo- cations. --noop-exit code Exit with the specified error code if the command execution is a noop (performs no new package builds, upgrades, etc). --rebuild-checksum sum Hash the names, versions, and configurations of all the packages that would be built. If the resulting checksum matches the speci- fied, then exit without building anything (potentially with a spe- cial error code specified with the --noop-exit option). Otherwise, proceed to build as normal. In both cases, print the resulting checksum to stdout. --no-private-config code If no configuration of a suitable type is linked to build a build- time dependency, instead of automatically creating a private config- uration of this type, exit with the specified error code printing to stdout the dependency chain starting from the build-time dependency (together with its constraint, if present) and ending with the top- level dependent (together with their configuration directories), one entry per line. For example: yacc ^1.0.0 libbar/1.0.0 /path/to/libbar/cfg/ libfoo/1.0.0 /path/to/libfoo/cfg/ See bpkg-cfg-create(1) for details on linked configurations. --sys-no-query Do not query the system package manager for the installed versions of packages specified with the sys scheme. --sys-install Instruct the system package manager to install available versions of packages specified with the sys scheme that are not already in- stalled. See also the --sys-no-fetch, --sys-yes, and --sys-sudo op- tions. --sys-no-fetch Do not fetch the system package manager metadata before querying for available versions of packages specified with the sys scheme. This option only makes sense together with --sys-install. --sys-no-stub Do no require a stub for packages specified with the sys scheme. Note that this option has effect only if the system package manager interactions are supported and not disabled. --sys-yes Assume the answer to the system package manager prompts is yes. Note that system package manager interactions may break your system and you should normally only use this option on throw-away setups (test virtual machines, etc). --sys-sudo prog The sudo program to use for system package manager interactions that normally require administrative privileges (fetch package metadata, install packages, etc). If unspecified, sudo is used by default. Pass empty or the special false value to disable the use of the sudo program. Note that the sudo program is normally only needed if the system package installation is enabled with the --sys-install op- tion. --sys-distribution name Alternative system/distribution package manager to interact with. The valid name values are debian (Debian and alike, such as Ubuntu, etc) and fedora (Fedora and alike, such as RHEL, CentOS, etc). Note that some package managers may only be supported when running on certain host operating systems. --sys-architecture name Alternative architecture to use when interacting with the system package manager. The valid name values are system/distribution pack- age manager-specific. If unspecified, the host architecture is used. --directory|-d dir Assume current configuration is in dir rather than in the current working directory. Repeat this option to specify multiple current configurations. If multiple configurations are specified, they need not belong to the same linked configuration cluster. COMMON OPTIONS The common options are summarized below with a more detailed description available in bpkg-common-options(1). -v Print essential underlying commands being executed. -V Print all underlying commands being executed. --quiet|-q Run quietly, only printing error messages. --verbose level Set the diagnostics verbosity to level between 0 and 6. --stdout-format format Representation format to use for printing to stdout. --jobs|-j num Number of jobs to perform in parallel. --no-result Don't print informational messages about the outcome of performing a command or some of its parts. --structured-result fmt Write the result of performing a command in a structured form. --progress Display progress indicators for long-lasting operations, such as network transfers, building, etc. --no-progress Suppress progress indicators for long-lasting operations, such as network transfers, building, etc. --diag-color Use color in diagnostics. --no-diag-color Don't use color in diagnostics. --build path The build program to be used to build packages. --build-option opt Additional option to be passed to the build program. --fetch path The fetch program to be used to download resources (packages, repos- itory metadata, etc). --fetch-option opt Additional option to be passed to the fetch program. --fetch-timeout sec The fetch and fetch-like (for example, git) program timeout. --offline Do not attempt to download resources (packages, repository metadata, etc), instead taking them from the local fetch cache if available and failing otherwise. --no-fetch-cache Disable local caching of downloaded resources (packages, repository metadata, etc). --fetch-cache mode Comma-separated list of local fetch cache modes. --fetch-cache-path dir The directory of the local fetch cache. --fetch-cache-session id The local fetch cache session. --sqlite-synchronous mode Filesystem synchronization mode for the fetch cache and configura- tion SQLite databases. --pkg-proxy url HTTP proxy server to use when fetching package manifests and archives from remote pkg repositories. --git path The git program to be used to fetch git repositories. --git-option opt Additional common option to be passed to the git program. --sha256 path The sha256 program to be used to calculate SHA256 sums. --sha256-option opt Additional option to be passed to the sha256 program. --tar path The tar program to be used to extract package archives. --tar-option opt Additional option to be passed to the tar program. --openssl path The openssl program to be used for crypto operations. --openssl-option opt Additional option to be passed to the openssl program. --auth type Types of repositories to authenticate. --trust fingerprint Trust repository certificate with a SHA256 fingerprint. --trust-yes Assume the answer to all authentication prompts is yes. --trust-no Assume the answer to all authentication prompts is no. --git-capabilities up=pc Protocol capabilities (pc) for a git repository URL prefix (up). --pager path The pager program to be used to show long text. --pager-option opt Additional option to be passed to the pager program. --options-file file Read additional options from file. --default-options dir The directory to load additional default options files from. --no-default-options Don't load default options files. --keep-tmp Don't remove the bpkg's temporary directory at the end of the com- mand execution and print its path at the verbosity level 2 or higher. DEFAULT OPTIONS FILES See bpkg-default-options-files(1) for an overview of the default options files. For the pkg-build command the search start directory is the configu- ration directory. The following options files are searched for in each di- rectory and, if found, loaded in the order listed: bpkg.options bpkg-pkg-build.options The following pkg-build command options cannot be specified in the default options files: --directory|-d BUGS Send bug reports to the users@build2.org mailing list. COPYRIGHT Copyright (c) 2014-2026 the build2 authors. Permission is granted to copy, distribute and/or modify this document under the terms of the MIT License. bpkg 0.18.0 April 2026 bpkg-pkg-build(1)
NAME | SYNOPSIS | DESCRIPTION | PKG-BUILD PACKAGE OPTIONS | PKG-BUILD GLOBAL OPTIONS | COMMON OPTIONS | DEFAULT OPTIONS FILES | BUGS | COPYRIGHT
Want to link to this manual page? Use this URL:
<https://man.FreeBSD.org/cgi/man.cgi?query=bpkg-pkg-build&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>