bpkg-pkg-status(1)

🌟 NAME 🌟

bpkg-pkg-status — print package status.

Okay so real talk, this is the bpkg-pkg-status(1) page from the General Commands Manual, and it's a big one — so big it got split into parts. This is part 1, bestie. Grab a snack. 🍓

---

✨ SYNOPSIS ✨

bpkg pkg-status|status [options] [pkg[/ver]...]

---

🦋 DESCRIPTION 🦋

The pkg-status command prints the status of the packages you name — or, if you give it a ver, the status of those package versions. If you name no packages at all, then pkg-status prints the status of every held package (and held packages are the ones that were explicitly built, okay? go peek at bpkg-pkg-build(1) if you need the lore). That last mode can be switched up to print the status of all the packages by passing the --all|-a option. On top of that, you can also get the status of immediate dependencies or all dependencies of those packages by passing --immediate|-i or --recursive|-r respectively. And no cap — the status goes to stdout, not stderr. 🙈

The default output format (see the --stdout-format common option) is regular, with components separated by spaces. Each line kicks off with the package name, then one of the status words listed below. Some of them can optionally be followed by a , (no spaces!!) and a sub-status word. Lines that correspond to dependencies from linked configurations will also mention the configuration directory in square brackets after the package name. 💅

• unknown — Package is not part of the configuration nor available from any of the repositories.
• available — Package is not part of the configuration but is available from one of the repositories.
• fetched — Package is part of the configuration and is fetched.
• unpacked — Package is part of the configuration and is unpacked.
• configured — Package is part of the configuration and is configured. May be followed by the system sub-status indicating a package coming from the system. The version of such a system package (described below) may be the special * value indicating a wildcard version.
• broken — Package is part of the configuration and is broken (broken packages can only be purged; see bpkg-pkg-purge(1)).

If you only gave the package name without the package version, then the available status word gets followed by the list of available versions. Versions that are only available for up/down-grading get printed in [] (such versions are only available as dependencies from prerequisite repositories of other repositories). If the --system option is specified, then the last version in this list may have the sys: prefix, indicating an available system version. Such a system version may be the special ? value, which means a package may or may not be available from the system and that its version is unknown. 👑

The fetched, unpacked, configured, and broken status words are followed by the version of the package. And if the package version was specified, then the unknown status word is also followed by the version.

If the status is fetched, unpacked, configured, or broken and newer versions are available, then the package version is followed by the available status word and the list of newer versions. To instead see a list of all versions, older ones included, pass the --old-available|-o option. In that case the currently selected version gets printed in (). 🎀

If the package name was specified with the version, then only the status (like configured, available, etc.) of that version is considered.

If a package is being held, then its name is printed prefixed with !. Similarly, if a package version is being held, then the version is printed prefixed with !. Held packages and held versions were picked by the user and are not automatically dropped and upgraded, respectively. (That's the whole point, bestie — they're protected. 🫶)

Below are some examples, assuming the configuration has libfoo 1.0.0 configured and held (both package and version) as well as libfoo 1.1.0 and 1.1.1 available from source and 1.1.0 from the system.

bpkg status libbar
libbar unknown

bpkg status libbar/1.0.0
libbar unknown 1.0.0

bpkg status libfoo/1.0.0
!libfoo configured !1.0.0

bpkg status libfoo/1.1.0
libfoo available 1.1.0

bpkg status --system libfoo/1.1.0
libfoo available 1.1.0 sys:1.1.0

bpkg status libfoo
!libfoo configured !1.0.0 available 1.1.0 1.1.1

bpkg status libfoo/1.1.1 libbar
libfoo available 1.1.1
libbar unknown

Assuming now that we dropped libfoo from the configuration:

bpkg status libfoo/1.0.0
libfoo unknown 1.0.0

bpkg status libfoo
libfoo available 1.1.0 1.1.1

And assuming now that we built libfoo as a system package with the wildcard version:

bpkg status libfoo
!libfoo configured,system !* available 1.1.0 1.1.1

Another example of the status output, this time including dependencies:

bpkg status -r libbaz
!libbaz configured 1.0.0
  libfoo configured 1.0.0
    bison [.bpkg/host/] configured 1.0.0
  libbar configured 2.0.0

If the output format is json, then the output is a JSON array of objects, which are the serialized representation of the following C++ struct package_status:

struct available_version
{
  string version;
  bool   system;
  bool   dependency;
};

struct package_status
{
  string                    name;
  optional<string>          configuration;
  optional<string>          constraint;
  string                    status;
  optional<string>          sub_status;
  optional<string>          version;
  bool                      hold_package;
  bool                      hold_version;
  vector<available_version> available_versions;
  vector<package_status>    dependencies;
};

For example:

[
  {
    "name": "hello",
    "status": "configured",
    "version": "1.0.0",
    "hold_package": true,
    "available_versions": [
      {
        "version": "1.0.1"
      },
      {
        "version": "2.0.0"
      }
    ],
    "dependencies": [
      {
        "name": "libhello",
        "status": "configured",
        "version": "1.0.2",
      }
    ]
  }
]

See the JSON OUTPUT section in bpkg-common-options(1) for details on the overall properties of this format and the semantics of the struct serialization. ✨

In package_status, the configuration member contains the absolute directory of a linked configuration if this package resides in a linked configuration. The constraint member is present only if the --constraint option is specified. The version member is absent if the status member is unknown or available and no package version is specified on the command line. If the sub_status member is system, then the version member can be special *. The dependencies member is present only if the --immediate|-i or --recursive|-r options are specified.

In available_version, if the system member is true, then this version is available from the system, in which case the version member can be special ? or *. If the dependency member is true, then this version is only available as a dependency from prerequisite repositories of other repositories. 🔥

---

👑 PKG-STATUS OPTIONS 👑

• --all, -a — Print the status of all the packages, not just held.
• --link — Also print the status of held/all packages from linked configurations.
• --immediate, -i — Also print the status of immediate dependencies.
• --recursive, -r — Also print the status of all dependencies, recursively.
• --old-available, -o — Print old available versions.
• --constraint — Print version constraints for dependencies.
• --system — Check the availability of packages from the system.
• --no-hold — Don't print the package or version hold status.
• --no-hold-package — Don't print the package hold status.
• --no-hold-version — Don't print the version hold status.
• --directory, -d dir — Assume configuration is in dir rather than in the current working directory.

---

More parts incoming, don't go anywhere. 🌈

✨ COMMON OPTIONS ✨

okay bestie, these are the common options, summarized right here — but if you want the full deep-dive, it's all in bpkg-common-options(1). 💅

• -v — prints the essential underlying commands being executed. lowkey useful to see what's actually happening.
• -V — prints all the underlying commands being executed. highkey chaotic but iconic.
• --quiet|-q — run quietly, only printing error messages. no yapping.
• --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. we love a loading bar. 🫶
• --no-progress — suppress progress indicators for long-lasting operations, such as network transfers, building, etc.
• --diag-color — use color in diagnostics. pretty errors >>> 😭
• --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.
• --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.
• --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 command execution and print its path at the verbosity level 2 or higher.

---

🎀 DEFAULT OPTIONS FILES 🎀

For the whole overview of default options files, peek at bpkg-default-options-files(1). For the pkg-status command, the search start directory is the configuration directory. In each directory, these files are searched for and, if found, loaded in the order listed:

bpkg.options
bpkg-pkg-status.options

And these pkg-status command options cannot be specified in the default options files:

• --directory|-d

---

🐛 BUGS 🐛

Found a bug? Send bug reports to the users@build2.org mailing list. bestie behavior, fr fr. 💌

---

👑 COPYRIGHT 👑

Copyright (c) 2014-2024 the build2 authors.

Permission is granted to copy, distribute and/or modify this document under the terms of the MIT License.

---

and that's the whole page, bestie — brought to you by bpkg 0.17.0, dated June 2024, and this absolute icon of a manual page is bpkg-pkg-status(1). periodt 💅✨