---
name: "pkgpath"
section: "7"
platform: "openbsd"
package: "man"
version: "8.0-current-20261101"
release: "OpenBSD 8.0-current (2026-11-01)"
platforms: ["openbsd"]
url: "https://new.carta.tech/pkgpath"
---

# pkgpath(7)

ports tree location for a package build

## NAME

**pkgpath** – ports tree location for a package build

## DESCRIPTION

Each location in the ports tree is uniquely identified through a **pkgpath**, which encodes the directory, flavor and subpackage information that allows the build of a package. This is not to be confused with PKG\_PATH, the list of URLs from which pkg\_add(1) retrieves binary packages.

Every **pkgpath** conforms to the pattern *some/directory\[,-sub\]\[,flavor...\]*.

The *some/directory* part refers to the directory part, to find under the portstree, usually in */usr/ports* (or */usr/ports/mystuff* for port developers).

The *,-sub* optional part refers to a specific subpackage from a multi-package port. It can be left blank for non multi-package ports, or to get the default subpackage (usually *-main*).

The *,flavor...* optional part refers to the flavors or pseudo-flavors to use when building the package. If left blank, it refers to the default flavor. An explicit empty flavor can also be specified to make sure to get an empty flavor, even if it does not correspond to the default flavor.

Note that *-sub* and *flavor* parts can be specified in any order, as all subpackages start with a dash. It is an error to ask for several subs at once, e.g. *some/path,-sub1,-sub2*, though it won't always be flagged as a problem.

For instance:

- *misc/screen*

  A simple directory, default flavor, which happens to be empty.

- *misc/screen,static*

  Same port, *static* flavor.

- *x11/kde/libs3*

  A multi-package port with no subpackage nor flavor, refers to *x11/kde/libs3,-main*.

- *net/avahi*

  Multi-package port with default flavor. Will actually build with FLAVOR="no\_gui no\_mono no\_qt3 no\_qt4 bootstrap" (all of which are pseudo-flavors), so that only the main package will build.

- *net/avahi,no\_mono,-qt3*

  Build avahi with the "no\_mono" pseudo-flavor, which will build the -main, -qt3, -qt4, -gui, -gtk, -gtk3, and -ui subpackages, and refer to the *-qt3* subpackage.

- *net/avahi,*

  *net/avahi* with an explicit empty flavor, default subpackage( which happens to be *-main*).

- *net/avahi,,-qt4*

  *net/avahi* with an explicit empty flavor, *-qt4* subpackage.

The ports tree can iterate over lists of **pkgpath** through SUBDIR="pkgpath1 pkgpath2..." or through a full list through SUBDIRLIST=file.

[dpb(1)](/dpb/1.md) also handles **pkgpath** lists for many options.

## NORMALISATION AND THE FULLPATH CONVENTION

When the ports tree handles dependencies, it passes **pkgpath** from BUILD\_DEPENDS, LIB\_DEPENDS, RUN\_DEPENDS, and TEST\_DEPENDS to the dependent port for normalisation purposes. That way, the **pkgpath** that gets recorded in the package doesn't have any "default" flavor or "default" subpackage left: those are always resolved to the correct value.

Likewise, pseudo-flavors vanish from the **pkgpath**, since they only participate in the build process, but do not intervene in the built package.

As a result, such **pkgpath** are slightly different from the description above, as a flavor left blank is the empty flavor (and not the default flavor). This is the "fullpath convention".

Tools such as [dpb(1)](/dpb/1.md) display fullpath pkgpaths, and binary packages store full pkgpaths.

SUBDIR and SUBDIRLIST can be forced to follow the fullpath convention by explicitly passing FULLPATH=Yes to the corresponding [make(1)](/make/1.md) invocations.

Most tools that process binary packages do so.

## SEE ALSO

[dpb(1)](/dpb/1.md), [bsd.port.mk(5)](/bsd.port.mk/5.md), [library-specs(7)](/library-specs/7.md), [packages(7)](/packages/7.md), [packages-specs(7)](/packages-specs/7.md), [ports(7)](/ports/7.md)