Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
PKG-REPOSITORY(5)	  FreeBSD File Formats Manual	     PKG-REPOSITORY(5)

     package repository	-- format and operation	of package repositories	used
     by	pkg(8).

     Package repositories used by the pkg(8) program consist of	one or more
     collections of "package tarballs" together	with package catalogues	and
     optionally	various	other collected	package	metadata.

     Each collection consists of packages suitable for installation on a spe-
     cific system ABI: a combination of	operating system, CPU architecture, OS
     version, word size, and for certain processors endianness or similar at-

     The package collections are typically made	available to users for down-
     load via a	web or FTP server although various other means of access may
     be	employed.  Encoding the	ABI value into the repository URL allows pkg
     to	automatically select the correct package collection by expanding the
     special token ${ABI} in pkg.conf.

     Repositories may be mirrored over several sites: pkg has built-in support
     for discovering available mirrors dynamically given a common URL by sev-
     eral mechanisms.

     Only very minimal constraints on repository layout	are prescribed by pkg.
     The following constraints are all that must be met:

     o	 A repository may contain several package collections with parallel
	 REPOSITORY_ROOTs in order to support diverse system ABIs.

     o	 All of	the content for	one ABI	should be accessible in	a filesystem
	 or URL	hierarchy beneath the REPOSITORY_ROOT.

     o	 All packages available	beneath	one REPOSITORY_ROOT should be binary
	 compatible with a specific system ABI.

     o	 The repository	catalogue is located at	the apex of the	repository, at
	 a specific location relative to the REPOSITORY_ROOT.

     Package catalogues	contain	the paths relative to the REPOSITORY_ROOT for
     each package, allowing the	full URL for downloading the package to	be

     Where a package may be applicable to more than one	ABI (e.g., it contains
     only text files) symbolic or hard links, URL mappings or other techniques
     may be utilised to	avoid duplication of storage.

     Although no specific filesystem organization is required, the usual con-
     vention (inherited	from pkg-install(8)) is	to create a filesystem hierar-
     chy thus:

		 One directory that contains every package available from the
		 repository for	that ABI.  Packages are	stored as package tar-
		 balls identified by name and version.	This directory may
		 contain several different versions of each package accumu-
		 lated over time, but the repository catalogue will only
		 record	the latest version for each distinct package name.

		 May contains symbolic links to	the latest versions of pack-
		 ages in the All directory.  Symbolic links contain a `latest
		 link' style name only,	without	version.  As the whole `latest
		 link' concept is rendered obsolete by pkg, this will usually
		 contain only the pkg.txz link,	used for bootstrapping pkg it-
		 self on a new system.

		 Contains one JSON document, which is the concatenation	of the
		 +MANIFEST files from each of the packages in the repository.
		 This is used by pkg-1.1 or later.

		 (Deprecated).	Contains the package manifest data as above,
		 but pre-loaded	into an	SQLite database.  This is supplied for
		 backwards compatibility with pkg-1.0.

		 (Optional).  Contains a YAML document listing all of the
		 files contained in all	of the packages	within the repository.

		 The repository	may optionally contain sub-directories corre-
		 sponding to the package origins within	the ports tree.

     Each of the packages listed in the	repository catalogue must have a
     unique name.  There are no	other constraints: package sets	are not	re-
     quired to be either complete (i.e., with all dependencies satisfied) or
     self-consistent within a single repository.

     pkg uses standard network protocols for repository	access.	 Any URL
     scheme understood by the fetch(3) library may be used (HTTP, HTTPS, FTP
     or	FILE) as well as remote	access over SSH.  See fetch(3) for a descrip-
     tion of additional	environment variables, including FETCH_BIND_ADDRESS,
     HTTP_USER_AGENT, NETRC, NO_PROXY and no_proxy.

     Multiple copies of	a repository can be provided for resilience or to
     scale up site capacity.  Two schemes are provided to auto-discover	sets
     of	mirrors	given a	single repository URL.

     HTTP  The repository URL should download a	text document containing a se-
	   quence of lines beginning with `URL:' followed by any amount	of
	   white space and one URL for a repository mirror.  Any lines not
	   matching this pattern are ignored.  Mirrors are tried in the	order
	   listed until	a download succeeds.

     SRV   For an SRV mirrored repository where	the URL	is specified as SRV records should be set up in the

		 _http._tcp.pkgrepo IN SRV 10 1	80 mirror0
				    IN SRV 20 1	80 mirror1

	   where the SRV priority and weight parameters	are used to control
	   search order	and traffic weighting between sites, and the port num-
	   ber and hostname are	used to	construct the individual mirror	URLs.

     Mirrored repositories are assumed to have identical content, and only one
     copy of the repository catalogue will be downloaded to apply to all mir-
     ror sites.

     Where several different repositories are configured pkg will search
     amongst them all in the order specified by	the PRIORITY settings in the
     repo.conf files, unless directed to use a single repository by the	-r
     flag to pkg-fetch(8), pkg-install(8), pkg-upgrade(8), pkg-search(8) or

     Where several different versions of the same package are available, pkg
     will select the one with the highest version to install or	to upgrade an
     installed package to, even	if a lower numbered version can	be found in a
     repository	earlier	in the list.  This applies even	if an explicit version
     is	stated on the command line.  Thus if packages example-1.0.0 and
     example-1.0.1 are available in configured repositories, then

	   pkg install example-1.0.0

     will actually result in example-1.0.1 being installed.  To	override this
     behaviour,	on first installation of the package select the	repository
     with the appropriate version:

	   pkg install -r repo-a example-1.0.0

     and then to make updates to that package "sticky" to the same repository,
     set the value CONSERVATIVE_UPGRADE	to true	in pkg.conf.

     pkg_printf(3), pkg_repos(3), pkg-lua-script(5), pkg-script(5),
     pkg.conf(5), pkg(8), pkg-add(8), pkg-alias(8), pkg-annotate(8),
     pkg-audit(8), pkg-autoremove(8), pkg-backup(8), pkg-check(8),
     pkg-clean(8), pkg-config(8), pkg-create(8), pkg-delete(8),	pkg-fetch(8),
     pkg-info(8), pkg-install(8), pkg-lock(8), pkg-query(8), pkg-register(8),
     pkg-repo(8), pkg-rquery(8), pkg-search(8),	pkg-set(8), pkg-shell(8),
     pkg-shlib(8), pkg-ssh(8), pkg-stats(8), pkg-update(8), pkg-updating(8),
     pkg-upgrade(8), pkg-version(8), pkg-which(8)

FreeBSD	13.0		       February	1, 2015			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help