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

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
PKG-REPOSITORY(5)	  FreeBSD File Formats Manual	     PKG-REPOSITORY(5)

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

DESCRIPTION
     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
     attributes.

     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.

FILESYSTEM ORGANIZATION
     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
     constructed.

     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:

     $REPOSITORY_ROOT/All
		 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 origin.

     $REPOSITORY_ROOT/Latest/
		 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
		 itself	on a new system.

     $REPOSITORY_ROOT/digests.txz
		 Package checksum data and optionally package signatures.

     $REPOSITORY_ROOT/packagesite.txz
		 Contains one YAML 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.

     $REPOSITORY_ROOT/repo.txz
		 (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.

     $REPOSITORY_ROOT/filesite.txz
		 (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 origin.  There are no other	constraints: package sets are not
     required to be either complete (i.e., with	all dependencies satisfied) or
     self-consistent within a single repository.

REPOSITORY ACCESS METHODS
     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,
     FTP_LOGIN,	FTP_PASSIVE_MODE, FTP_PASSWORD,	FTP_PROXY, ftp_proxy,
     HTTP_AUTH,	HTTP_PROXY, http_proxy,	HTTP_PROXY_AUTH, HTTP_REFERER,
     HTTP_USER_AGENT, NETRC, NO_PROXY and no_proxy.

REPOSITORY MIRRORING
     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
	   sequence of lines beginning with `URL:' followed by any amount of
	   while 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
	   http://pkgrepo.example.org/ SRV records should be set up in the
	   DNS:

		 $ORIGIN example.com
		 _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.

WORKING	WITH MULTIPLE REPOSITORIES
     Where several different repositories are configured pkg will search
     amongst them all in the order specified, 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 pkg-rquery(8).  The search order is as
     displayed in the output of

	   pkg -v -v

     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 reposi-
     tory, add an annotation to	the package:

	   pkg annotate	-A example repository repo-a

SEE ALSO
     pkg(8) pkg.conf(5)	pkg-repo(8) fetch(3)

FreeBSD	10.1		      September	30, 2013		  FreeBSD 10.1

NAME | DESCRIPTION | FILESYSTEM ORGANIZATION | REPOSITORY ACCESS METHODS | REPOSITORY MIRRORING | WORKING WITH MULTIPLE REPOSITORIES | SEE ALSO

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=pkg-repository&sektion=5&manpath=FreeBSD+10.0-RELEASE>

home | help