The Ur Project

Documenting the craft of stacking things so they remain stacked. For a very long time.

pkg-info(1)

NAME

pkg-info - print details of a manifest, by name or by path

SYNOPSIS

pkg info target

DESCRIPTION

Every subpackage is published as a signed manifest: a small TOML file that says what the package is, which payload it ships and what's in it. The bytes themselves live elsewhere, by checksum. pkg info prints the top of one of those manifests: identity, payload, license and file count.

This is a question for the repository, not for your machine. It tells you what's on offer. For what's actually installed, use pkg-query(1).

Name or path?

target can be either, and pkg works out which:

A path
If the argument names a file that exists, it's parsed as a manifest directly. That works on any manifest anywhere, including one that was never published in a repository.
A spec
Otherwise it's taken as name or name/subpkg and looked up in the repository chain, at the build the named pointer makes current. It's never "the highest version I can find on disk".

Why won't it take a bare name?

It will, as long as that name means one thing. info prints exactly one manifest, so a bare name has to land on exactly one runtime subpackage. When several qualify, pkg won't pick one for you. It names them and asks:

error: invalid argument: alsa-lib is 3 runtime subpackages; name one (alsa-lib/bin, alsa-lib/data, alsa-lib/lib)

OPTIONS

None of its own. All global options apply; see pkg(1).

OUTPUT

alsa-lib/lib 1.2.16.1-2 x86_64 payload: ed6c685fda519eaa113fb9f265786b3916d608cc53e7cfd9d5c8bbe5cc22cc77 (596984 bytes, tar.zst) license: LGPL-2.1-or-later files: 4

JSON

{ "ok": true, "name": "alsa-lib", "subpkg": "lib", "version": "1.2.16.1", "release": 2, "arch": "x86_64", "payload": { "algorithm": "tar.zst", "sha256": "...", "size": 596984 }, "license": "LGPL-2.1-or-later", "file_count": 4 }

EXAMPLES

By name

pkg info gzip/bin pkg info alsa-lib/lib

By path

pkg info /data/repo/Common/pkgs/gzip/bin/1.13/4/x86_64/pkg-meta

Against a repository that isn't configured

pkg --repo /srv/mirror/Common --repos-dir /nonexistent info gzip/bin

Against a signed remote

pkg --repo-url http://repo.example:8082/Common \ --tuf-root /etc/pkg/common.root.json info gzip/bin

Getting the payload digest for a manual fetch

sha=$(pkg --json info gzip/bin | jq -r .payload.sha256) echo "data/${sha:0:2}/${sha:2:2}/$sha"

The digest is the payload's address in the repository. That's the whole trick.

Is what's offered what I have?

pkg info openssl/lib pkg query openssl/lib

Different versions mean an upgrade is pending. The same version with a different payload digest means a rebuild, or a repository move. See pkg-upgrade(1).

Licenses across a set

for m in $(pkg --json set show +console | jq -r '.expanded[]'); do pkg --json info "$m" 2>/dev/null | jq -r '"(.name)\t(.license)"' done

Sizes, largest first

pkg --json list --all | jq -r '.packages[] | "(.name)/(.subpkg)"' \ | while read -r p; do pkg --json info "$p" | jq -r '"(.payload.size)\t(.name)/(.subpkg)"' done | sort -rn | head -20

Checking the signature on the same manifest

pkg verify-sig /data/repo/Common/pkgs/gzip/bin/1.13/4/x86_64/pkg-meta

Following it back to where it was built

pkg provenance verify /data/repo/Common/pkgs/gzip/bin/1.13/4/x86_64/pkg-meta

EXIT STATUS

0 on success. 1 when the target is neither an existing file nor a spec that resolves, when a bare name matches several runtime subpackages, or when a repository without a pointer holds the name at several builds.

SEE ALSO

pkg(1), pkg-query(1), pkg-search(1), pkg-list(1), pkg-verify-sig(1), pkg-provenance(1), pkg-chain(7), pkg-repository-layout(7), pkg-subpkgs(7)

docs/design/format.md