5.4. The Distribution Files

The second part of the Makefile describes the files that must be downloaded to build the port, and where they can be downloaded.


DISTNAME is the name of the port as called by the authors of the software. DISTNAME defaults to ${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}, and DISTVERSION defaults to ${PORTVERSION} so override DISTNAME only if necessary. DISTNAME is only used in two places. First, the distribution file list (DISTFILES) defaults to ${DISTNAME}${EXTRACT_SUFX}. Second, the distribution file is expected to extract into a subdirectory named WRKSRC, which defaults to work/${DISTNAME}.

Some vendor's distribution names which do not fit into the ${PORTNAME}-${PORTVERSION}-scheme can be handled automatically by setting DISTVERSIONPREFIX, DISTVERSION, and DISTVERSIONSUFFIX. PORTVERSION will be derived from DISTVERSION automatically.


Only one of PORTVERSION and DISTVERSION can be set at a time. If DISTVERSION does not derive a correct PORTVERSION, do not use DISTVERSION.

If the upstream version scheme can be derived into a ports-compatible version scheme, set some variable to the upstream version, do not use DISTVERSION as the variable name. Set PORTVERSION to the computed version based on the variable you created, and set DISTNAME accordingly.

If the upstream version scheme cannot easily be coerced into a ports-compatible value, set PORTVERSION to a sensible value, and set DISTNAME with PORTNAME with the verbatim upstream version.

Example 5.1. Deriving PORTVERSION Manually

BIND9 uses a version scheme that is not compatible with the ports versions (it has - in its versions) and cannot be derived using DISTVERSION because after the 9.9.9 release, it will release a patchlevels in the form of 9.9.9-P1. DISTVERSION would translate that into 9.9.9.p1, which, in the ports versioning scheme means 9.9.9 pre-release 1, which is before 9.9.9 and not after. So PORTVERSION is manually derived from an ISCVERSION variable in order to output 9.9.9p1.

The order into which the ports framework, and pkg, will sort versions is checked using the -t argument of pkg-version(8):

% pkg version -t 9.9.9 9.9.9.p1
> 1
% pkg version -t 9.9.9 9.9.9p1
< 2


The > sign means that the first argument passed to -t is greater than the second argument. 9.9.9 is after 9.9.9.p1.


The < sign means that the first argument passed to -t is less than the second argument. 9.9.9 is before 9.9.9p1.

In the port Makefile, for example dns/bind99, it is achieved by:

PORTVERSION=	${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} 1
CATEGORIES=	dns net ipv6

COMMENT=	BIND DNS suite with updated DNSSEC and DNS64


# ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like
ISCVERSION=	9.9.9-P6 4


Define upstream version in ISCVERSION, with a comment saying why it is needed.


Use ISCVERSION to get a ports-compatible PORTVERSION.


Use ISCVERSION directly to get the correct URL for fetching the distribution file.


Use ISCVERSION directly to name the distribution file.

Example 5.2. Derive DISTNAME from PORTVERSION

From time to time, the distribution file name has little or no relation to the version of the software.

In comms/kermit, only the last element of the version is present in the distribution file:

PORTNAME=	kermit
CATEGORIES=	comms ftp net
MASTER_SITES=	ftp://ftp.kermitproject.org/kermit/test/tar/


The :E make(1) modifier returns the suffix of the variable, in this case, 304. The distribution file is correctly generated as cku304-dev20.tar.gz.

Example 5.3. Exotic Case 1

Sometimes, there is no relation between the software name, its version, and the distribution file it is distributed in.

From audio/libworkman:

PORTNAME=       libworkman
CATEGORIES=     audio
DISTNAME=       ${PORTNAME}-1999-06-20

Example 5.4. Exotic Case 2

In comms/librs232, the distribution file is not versioned, so using DIST_SUBDIR is needed:

PORTNAME=       librs232
PORTVERSION=    20160710
CATEGORIES=     comms
MASTER_SITES=   http://www.teuniz.net/RS-232/
DISTNAME=       RS-232

Table 5.2. Examples of DISTVERSION and the Derived PORTVERSION


PKGNAMEPREFIX and PKGNAMESUFFIX do not affect DISTNAME. Also note that if WRKSRC is equal to ${WRKDIR}/${DISTNAME} while the original source archive is named something other than ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}, leave DISTNAME alone— defining only DISTFILES is easier than both DISTNAME and WRKSRC (and possibly EXTRACT_SUFX).


Record the directory part of the FTP/HTTP-URL pointing at the original tarball in MASTER_SITES. Do not forget the trailing slash (/)!

The make macros will try to use this specification for grabbing the distribution file with FETCH if they cannot find it already on the system.

It is recommended that multiple sites are included on this list, preferably from different continents. This will safeguard against wide-area network problems. We are even planning to add support for automatically determining the closest master site and fetching from there; having multiple sites will go a long way towards helping this effort.


MASTER_SITES must not be blank. It must point to the actual site hosting the distribution files. It cannot point to web archives, or the FreeBSD distribution files cache sites. The only exception to this rule is ports that do not have any distribution files. For example, meta-ports do not have any distribution files, so MASTER_SITES does not need to be set. Using MASTER_SITE_* Variables

Shortcut abbreviations are available for popular archives like SourceForge (SOURCEFORGE), GNU (GNU), or Perl CPAN (PERL_CPAN). MASTER_SITES can use them directly:


The older expanded format still works, but all ports have been converted to the compact format. The expanded format looks like this:


These values and variables are defined in Mk/bsd.sites.mk. New entries are added often, so make sure to check the latest version of this file before submitting a port.


For any MASTER_SITE_FOO variable, the shorthand FOO can be used. For example, use:


If MASTER_SITE_SUBDIR is needed, use this:



Some MASTER_SITE_* names are quite long, and for ease of use, shortcuts have been defined:

Table 5.3. Shortcuts for MASTER_SITE_* Macros

Several magic macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will choose a subdirectory automatically. For a port named Stardict, of version 1.2.3, and hosted on SourceForge, adding this line:


infers a subdirectory named /project/stardict/stardict/1.2.3. If the inferred directory is incorrect, it can be overridden:

MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

This can also be written as

Table 5.4. Magic MASTER_SITES Macros
MacroAssumed subdirectory


If the distribution file comes from a specific commit or tag on GitHub for which there is no officially released file, there is an easy way to set the right DISTNAME and MASTER_SITES automatically. These variables are available:

Table 5.5. USE_GITHUB Description
GH_ACCOUNTAccount name of the GitHub user hosting the project${PORTNAME}
GH_PROJECTName of the project on GitHub${PORTNAME}
GH_TAGNAMEName of the tag to download (2.0.1, hash, ...) Using the name of a branch here is incorrect. It is also possible to use the hash of a commit id to do a snapshot.${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}
GH_SUBDIRWhen the software needs an additional distribution file to be extracted within ${WRKSRC}, this variable can be used. See the examples in Section, “Fetching Multiple Files from GitHub” for more information.(none)
GH_TUPLEGH_TUPLE allows putting GH_ACCOUNT, GH_PROJECT, GH_TAGNAME, and GH_SUBDIR into a single variable. The format is account:project:tagname:group/subdir. The /subdir part is optional. It is helpful when there is more than one GitHub project from which to fetch. 


Do not use GH_TUPLE for the default distribution file, as it has no default.

Example 5.5. Simple Use of USE_GITHUB

While trying to make a port for version 1.2.7 of pkg from the FreeBSD user on github, at https://github.com/freebsd/pkg, The Makefile would end up looking like this (slightly stripped for the example):


GH_ACCOUNT=	freebsd

It will automatically have MASTER_SITES set to GH GHC and WRKSRC to ${WRKDIR}/pkg-1.2.7.

Example 5.6. More Complete Use of USE_GITHUB

While trying to make a port for the bleeding edge version of pkg from the FreeBSD user on github, at https://github.com/freebsd/pkg, the Makefile ends up looking like this (slightly stripped for the example):

PORTNAME=	pkg-devel
PORTVERSION=	1.3.0.a.20140411

GH_ACCOUNT=	freebsd
GH_TAGNAME=	6dbb17b

It will automatically have MASTER_SITES set to GH GHC and WRKSRC to ${WRKDIR}/pkg-6dbb17b.


From time to time, GH_TAGNAME is a slight variation from DISTVERSION. For example, if the version is 1.0.2, the tag is v1.0.2. In those cases, it is possible to use DISTVERSIONPREFIX or DISTVERSIONSUFFIX:



It will automatically set GH_TAGNAME to v1.0.2, while WRKSRC will be kept to ${WRKDIR}/foo-1.0.2. Fetching Multiple Files from GitHub

The USE_GITHUB framework also supports fetching multiple distribution files from different places in GitHub. It works in a way very similar to Section 5.4.8, “Multiple Distribution or Patches Files from Multiple Locations”.

When fetching multiple files from GitHub, sometimes the default distribution file is not required. To disable fetching the default distribution, set:

USE_GITHUB=	nodefault

Multiple values are added to GH_ACCOUNT, GH_PROJECT, and GH_TAGNAME. Each different value is assigned a group. The main value can either have no group, or the :DEFAULT group. A value can be omitted if it is the same as the default as listed in Table 5.5, “USE_GITHUB Description”.

GH_TUPLE can also be used when there are a lot of distribution files. It helps keep the account, project, tagname, and group information at the same place.

For each group, a ${WRKSRC_group} helper variable is created, containing the directory into which the file has been extracted. The ${WRKSRC_group} variables can be used to move directories around during post-extract, or add to CONFIGURE_ARGS, or whatever is needed so that the software builds correctly.


The :group part must be used for only one distribution file. It is used as a unique key and using it more than once will overwrite the previous values.


As this is only syntastic sugar above DISTFILES and MASTER_SITES, the group names must adhere to the restrictions on group names outlined in Section 5.4.8, “Multiple Distribution or Patches Files from Multiple Locations”

Example 5.8. Use of USE_GITHUB with Multiple Distribution Files

From time to time, there is a need to fetch more than one distribution file. For example, when the upstream git repository uses submodules. This can be done easily using groups in the GH_* variables:


GH_ACCOUNT=	bar:icons,contrib
GH_PROJECT=	foo-icons:icons foo-contrib:contrib
GH_TAGNAME=	1.0:icons fa579bc:contrib
GH_SUBDIR=	ext/icons:icons

CONFIGURE_ARGS=	--with-contrib=${WRKSRC_contrib}

This will fetch three distribution files from github. The default one comes from foo/foo and is version 1.0.2. The second one, with the icons group, comes from bar/foo-icons and is in version 1.0. The third one comes from bar/foo-contrib and uses the Git commit fa579bc. The distribution files are named foo-foo-1.0.2_GH0.tar.gz, bar-foo-icons-1.0_GH0.tar.gz, and bar-foo-contrib-fa579bc_GH0.tar.gz.

All the distribution files are extracted in ${WRKDIR} in their respective subdirectories. The default file is still extracted in ${WRKSRC}, in this case, ${WRKDIR}/foo-1.0.2. Each additional distribution file is extracted in ${WRKSRC_group}. Here, for the icons group, it is called ${WRKSRC_icons} and it contains ${WRKDIR}/foo-icons-1.0. The file with the contrib group is called ${WRKSRC_contrib} and contains ${WRKDIR}/foo-contrib-fa579bc.

The software's build system expects to find the icons in a ext/icons subdirectory in its sources, so GH_SUBDIR is used. GH_SUBDIR makes sure that ext exists, but that ext/icons does not already exist. Then it does this:

      @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons

Example 5.9. Use of USE_GITHUB with Multiple Distribution Files Using GH_TUPLE

This is functionally equivalent to Example 5.8, “Use of USE_GITHUB with Multiple Distribution Files”, but using GH_TUPLE:


GH_TUPLE=	bar:foo-icons:1.0:icons/ext/icons \

CONFIGURE_ARGS=	--with-contrib=${WRKSRC_contrib}

Grouping was used in the previous example with bar:icons,contrib. Some redundant information is present with GH_TUPLE because grouping is not possible.

Example 5.10. How to Use USE_GITHUB with Git Submodules?

Ports with GitHub as an upstream repository sometimes use submodules. See git-submodule(1) for more information.

The problem with submodules is that each is a separate repository. As such, they each must be fetched separately.

Using finance/moneymanagerex as an example, its GitHub repository is https://github.com/moneymanagerex/moneymanagerex. It has a .gitmodules file at the root. This file describes all the submodules used in this repository, and lists additional repositories needed. This file will tell what additional repositories are needed:

[submodule "lib/wxsqlite3"]
	path = lib/wxsqlite3
	url = https://github.com/utelle/wxsqlite3.git
[submodule "3rd/mongoose"]
	path = 3rd/mongoose
	url = https://github.com/cesanta/mongoose.git
[submodule "3rd/LuaGlue"]
	path = 3rd/LuaGlue
	url = https://github.com/moneymanagerex/LuaGlue.git
[submodule "3rd/cgitemplate"]
	path = 3rd/cgitemplate
	url = https://github.com/moneymanagerex/html-template.git

The only information missing from that file is the commit hash or tag to use as a version. This information is found after cloning the repository:

% git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git
Cloning into 'moneymanagerex'...
remote: Counting objects: 32387, done.
Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue'
Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate'
Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose'
Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3'
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'...
Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b'
Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c'
Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda'
Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51'
% cd moneymanagerex
% git submodule status
 c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master)
 cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee)
 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59)
 fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0)

It can also be found on GitHub. Each subdirectory that is a submodule is shown as directory @ hash, for example, mongoose @ 2140e59.


While getting the information from GitHub seems more straightforward, the information found using git submodule status will provide more meaningful information. For example, here, lib/wxsqlite3's commit hash fb66eb2 correspond to v3.4.0. Both can be used interchangeably, but when a tag is available, use it.

Now that all the required information has been gathered, the Makefile can be written (only GitHub-related lines are shown):

PORTNAME=	moneymanagerex

GH_TUPLE=	utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \
		moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \
		moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \
		cesanta:mongoose:2140e59:mongoose/3rd/mongoose \


If there is one distribution file, and it uses an odd suffix to indicate the compression mechanism, set EXTRACT_SUFX.

For example, if the distribution file was named foo.tar.gzip instead of the more normal foo.tar.gz, write:

EXTRACT_SUFX=	.tar.gzip

The USES=tar[:xxx], USES=lha or USES=zip automatically set EXTRACT_SUFX to the most common archives extensions as necessary, see Chapter 15, Using USES Macros for more details. If neither of these are set then EXTRACT_SUFX defaults to .tar.gz.


As EXTRACT_SUFX is only used in DISTFILES, only set one of them..


Sometimes the names of the files to be downloaded have no resemblance to the name of the port. For example, it might be called source.tar.gz or similar. In other cases the application's source code might be in several different archives, all of which must be downloaded.

If this is the case, set DISTFILES to be a space separated list of all the files that must be downloaded.

DISTFILES=	source1.tar.gz source2.tar.gz

If not explicitly set, DISTFILES defaults to ${DISTNAME}${EXTRACT_SUFX}.


If only some of the DISTFILES must be extracted—for example, one of them is the source code, while another is an uncompressed document—list the filenames that must be extracted in EXTRACT_ONLY.

DISTFILES=	source.tar.gz manual.html
EXTRACT_ONLY=	source.tar.gz

When none of the DISTFILES need to be uncompressed, set EXTRACT_ONLY to the empty string.



If the port requires some additional patches that are available by FTP or HTTP, set PATCHFILES to the names of the files and PATCH_SITES to the URL of the directory that contains them (the format is the same as MASTER_SITES).

If the patch is not relative to the top of the source tree (that is, WRKSRC) because it contains some extra pathnames, set PATCH_DIST_STRIP accordingly. For instance, if all the pathnames in the patch have an extra foozolix-1.0/ in front of the filenames, then set PATCH_DIST_STRIP=-p1.

Do not worry if the patches are compressed; they will be decompressed automatically if the filenames end with .Z, .gz, .bz2 or .xz.

If the patch is distributed with some other files, such as documentation, in a gzipped tarball, using PATCHFILES is not possible. If that is the case, add the name and the location of the patch tarball to DISTFILES and MASTER_SITES. Then, use EXTRA_PATCHES to point to those files and bsd.port.mk will automatically apply them. In particular, do not copy patch files into ${PATCHDIR}. That directory may not be writable.


If there are multiple patches and they need mixed values for the strip parameter, it can be added alongside the patch name in PATCHFILES, e.g:

PATCHFILES=	patch1 patch2:-p1

This does not conflict with the master site grouping feature, adding a group also works:

PATCHFILES=	patch2:-p1:source2


The tarball will have been extracted alongside the regular source by then, so there is no need to explicitly extract it if it is a regular gzipped or compressed tarball. Take extra care not to overwrite something that already exists in that directory if extracting it manually. Also, do not forget to add a command to remove the copied patch in the pre-clean target.

5.4.8. Multiple Distribution or Patches Files from Multiple Locations

(Consider this to be a somewhat advanced topic; those new to this document may wish to skip this section at first).

This section has information on the fetching mechanism known as both MASTER_SITES:n and MASTER_SITES_NN. We will refer to this mechanism as MASTER_SITES:n.

A little background first. OpenBSD has a neat feature inside DISTFILES and PATCHFILES which allows files and patches to be postfixed with :n identifiers. Here, n can be any word containing [0-9a-zA-Z_] and denote a group designation. For example:

DISTFILES=	alpha:0 beta:1

In OpenBSD, distribution file alpha will be associated with variable MASTER_SITES0 instead of our common MASTER_SITES and beta with MASTER_SITES1.

This is a very interesting feature which can decrease that endless search for the correct download site.

Just picture 2 files in DISTFILES and 20 sites in MASTER_SITES, the sites slow as hell where beta is carried by all sites in MASTER_SITES, and alpha can only be found in the 20th site. It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend!

Now that you have the idea, just imagine more DISTFILES and more MASTER_SITES. Surely our distfiles survey meister would appreciate the relief to network strain that this would bring.

In the next sections, information will follow on the FreeBSD implementation of this idea. We improved a bit on OpenBSD's concept.


The group names cannot have dashes in them (-), in fact, they cannot have any characters out of the [a-zA-Z0-9_] range. This is because, while make(1) is ok with variable names containing dashes, sh(1) is not. Simplified Information

This section explains how to quickly prepare fine grained fetching of multiple distribution files and patches from different sites and subdirectories. We describe here a case of simplified MASTER_SITES:n usage. This will be sufficient for most scenarios. More detailed information are available in Section, “Detailed Information”.

Some applications consist of multiple distribution files that must be downloaded from a number of different sites. For example, Ghostscript consists of the core of the program, and then a large number of driver files that are used depending on the user's printer. Some of these driver files are supplied with the core, but many others must be downloaded from a variety of different sites.

To support this, each entry in DISTFILES may be followed by a colon and a group name. Each site listed in MASTER_SITES is then followed by a colon, and the group that indicates which distribution files are downloaded from this site.

For example, consider an application with the source split in two parts, source1.tar.gz and source2.tar.gz, which must be downloaded from two different sites. The port's Makefile would include lines like Example 5.11, “Simplified Use of MASTER_SITES:n with One File Per Site”.

Example 5.11. Simplified Use of MASTER_SITES:n with One File Per Site
MASTER_SITES=	ftp://ftp1.example.com/:source1 \
DISTFILES=	source1.tar.gz:source1 \

Multiple distribution files can have the same group. Continuing the previous example, suppose that there was a third distfile, source3.tar.gz, that is downloaded from ftp.example2.com. The Makefile would then be written like Example 5.12, “Simplified Use of MASTER_SITES:n with More Than One File Per Site”.

Example 5.12. Simplified Use of MASTER_SITES:n with More Than One File Per Site
MASTER_SITES=	ftp://ftp.example.com/:source1 \
DISTFILES=	source1.tar.gz:source1 \
		source2.tar.gz:source2 \
		source3.tar.gz:source2 Detailed Information

Okay, so the previous example did not reflect the new port's needs? In this section we will explain in detail how the fine grained fetching mechanism MASTER_SITES:n works and how it can be used.

  1. Elements can be postfixed with :n where n is [^:,]+, that is, n could conceptually be any alphanumeric string but we will limit it to [a-zA-Z_][0-9a-zA-Z_]+ for now.

    Moreover, string matching is case sensitive; that is, n is different from N.

    However, these words cannot be used for postfixing purposes since they yield special meaning: default, all and ALL (they are used internally in item ii). Furthermore, DEFAULT is a special purpose word (check item 3).

  2. Elements postfixed with :n belong to the group n, :m belong to group m and so forth.

  3. Elements without a postfix are groupless, they all belong to the special group DEFAULT. Any elements postfixed with DEFAULT, is just being redundant unless an element belongs to both DEFAULT and other groups at the same time (check item 5).

    These examples are equivalent but the first one is preferred:

    MASTER_SITES=	alpha
  4. Groups are not exclusive, an element may belong to several different groups at the same time and a group can either have either several different elements or none at all.

  5. When an element belongs to several groups at the same time, use the comma operator (,).

    Instead of repeating it several times, each time with a different postfix, we can list several groups at once in a single postfix. For instance, :m,n,o marks an element that belongs to group m, n and o.

    All these examples are equivalent but the last one is preferred:

    MASTER_SITES=	alpha alpha:SOME_SITE
  6. All sites within a given group are sorted according to MASTER_SORT_AWK. All groups within MASTER_SITES and PATCH_SITES are sorted as well.

  7. Group semantics can be used in any of the variables MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES, and PATCHFILES according to this syntax:

    1. All MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR elements must be terminated with the forward slash / character. If any elements belong to any groups, the group postfix :n must come right after the terminator /. The MASTER_SITES:n mechanism relies on the existence of the terminator / to avoid confusing elements where a :n is a valid part of the element with occurrences where :n denotes group n. For compatibility purposes, since the / terminator was not required before in both MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR elements, if the postfix immediate preceding character is not a / then :n will be considered a valid part of the element instead of a group postfix even if an element is postfixed with :n. See both Example 5.13, “Detailed Use of MASTER_SITES:n in MASTER_SITE_SUBDIR and Example 5.14, “Detailed Use of MASTER_SITES:n with Comma Operator, Multiple Files, Multiple Sites and Multiple Subdirectories”.

      Example 5.13. Detailed Use of MASTER_SITES:n in MASTER_SITE_SUBDIR
      MASTER_SITE_SUBDIR=	old:n new/:NEW
      • Directories within group DEFAULT -> old:n

      • Directories within group NEW -> new

      Example 5.14. Detailed Use of MASTER_SITES:n with Comma Operator, Multiple Files, Multiple Sites and Multiple Subdirectories
      MASTER_SITES=	http://site1/%SUBDIR%/ http://site2/:DEFAULT \
      		http://site3/:group3 http://site4/:group4 \
      		http://site5/:group5 http://site6/:group6 \
      		http://site7/:DEFAULT,group6 \
      		http://site8/%SUBDIR%/:group6,group7 \
      DISTFILES=	file1 file2:DEFAULT file3:group3 \
      		file4:group4,group5,group6 file5:grouping \
      MASTER_SITE_SUBDIR=	directory-trial:1 directory-n/:groupn \
      		directory-one/:group6,DEFAULT \

      The previous example results in this fine grained fetching. Sites are listed in the exact order they will be used.

      • file1 will be fetched from


        • http://site1/directory-trial:1/

        • http://site1/directory-one/

        • http://site1/directory/

        • http://site2/

        • http://site7/


      • file2 will be fetched exactly as file1 since they both belong to the same group


        • http://site1/directory-trial:1/

        • http://site1/directory-one/

        • http://site1/directory/

        • http://site2/

        • http://site7/


      • file3 will be fetched from


        • http://site3/


      • file4 will be fetched from


        • http://site4/

        • http://site5/

        • http://site6/

        • http://site7/

        • http://site8/directory-one/


      • file5 will be fetched from



      • file6 will be fetched from


        • http://site8/


  8. How do I group one of the special macros from bsd.sites.mk, for example, SourceForge (SF)?

    This has been simplified as much as possible. See Example 5.15, “Detailed Use of MASTER_SITES:n with SourceForge (SF)”.

    Example 5.15. Detailed Use of MASTER_SITES:n with SourceForge (SF)
    MASTER_SITES=	http://site1/ SF/something/1.0:sourceforge,TEST
    DISTFILES=	something.tar.gz:sourceforge

    something.tar.gz will be fetched from all sites within SourceForge.

  9. How do I use this with PATCH*?

    All examples were done with MASTER* but they work exactly the same for PATCH* ones as can be seen in Example 5.16, “Simplified Use of MASTER_SITES:n with PATCH_SITES.

    Example 5.16. Simplified Use of MASTER_SITES:n with PATCH_SITES
    PATCH_SITES=	http://site1/ http://site2/:test
    PATCHFILES=	patch1:test What Does Change for Ports? What Does Not?

  1. All current ports remain the same. The MASTER_SITES:n feature code is only activated if there are elements postfixed with :n like elements according to the aforementioned syntax rules, especially as shown in item 7.

  2. The port targets remain the same: checksum, makesum, patch, configure, build, etc. With the obvious exceptions of do-fetch, fetch-list, master-sites and patch-sites.

    • do-fetch: deploys the new grouping postfixed DISTFILES and PATCHFILES with their matching group elements within both MASTER_SITES and PATCH_SITES which use matching group elements within both MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR. Check Example 5.14, “Detailed Use of MASTER_SITES:n with Comma Operator, Multiple Files, Multiple Sites and Multiple Subdirectories”.

    • fetch-list: works like old fetch-list with the exception that it groups just like do-fetch.

    • master-sites and patch-sites: (incompatible with older versions) only return the elements of group DEFAULT; in fact, they execute targets master-sites-default and patch-sites-default respectively.

      Furthermore, using target either master-sites-all or patch-sites-all is preferred to directly checking either MASTER_SITES or PATCH_SITES. Also, directly checking is not guaranteed to work in any future versions. Check item B for more information on these new port targets.

  3. New port targets

    1. There are master-sites-n and patch-sites-n targets which will list the elements of the respective group n within MASTER_SITES and PATCH_SITES respectively. For instance, both master-sites-DEFAULT and patch-sites-DEFAULT will return the elements of group DEFAULT, master-sites-test and patch-sites-test of group test, and thereon.

    2. There are new targets master-sites-all and patch-sites-all which do the work of the old master-sites and patch-sites ones. They return the elements of all groups as if they all belonged to the same group with the caveat that it lists as many MASTER_SITE_BACKUP and MASTER_SITE_OVERRIDE as there are groups defined within either DISTFILES or PATCHFILES; respectively for master-sites-all and patch-sites-all.


Do not let the port clutter /usr/ports/distfiles. If the port requires a lot of files to be fetched, or contains a file that has a name that might conflict with other ports (for example, Makefile), set DIST_SUBDIR to the name of the port (${PORTNAME} or ${PKGNAMEPREFIX}${PORTNAME} are fine). This will change DISTDIR from the default /usr/ports/distfiles to /usr/ports/distfiles/${DIST_SUBDIR}, and in effect puts everything that is required for the port into that subdirectory.

It will also look at the subdirectory with the same name on the backup master site at ftp.FreeBSD.org. (Setting DISTDIR explicitly in Makefile will not accomplish this, so please use DIST_SUBDIR.)


This does not affect MASTER_SITES defined in the Makefile.

All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.