MacPorts Guide
22/09/17 8:30 p.m.
Guide Mark ark Duli Dulin ng
Dr. Dr. Micha ichael el A Maiba aibaum um
Will Will Bar Barton ton
Copyright © 2007–2014 The MacPorts Project Copyright © 2002–2004 The OpenDarwin Project
Clem Clemen ens s Lang ang
Single Page Chunked
Chapter 1. Introduction MacPorts is an easy to use system for compiling, installing, and managing open source software. MacPorts may be conceptually divided into two main parts: the infrastructure, known as MacPorts base, and the set of available ports. A MacPorts port is a set of specifications contained in a Portfile Portfile that that defines an application, its characteristics, and any files or special instructions required to install it. This allows you to use a single command to tell MacPorts to automatically download, compile, and install applications and libraries. But using MacPorts to manage your open source software provides several other other significant advantages. advantages. For example, MacPorts: Installs automatically any required support software, known as dependencies , for a given port. Provides for uninstalls and upgrades for installed ports. Confines ported software to a private “sandbox” that keeps it from intermingling with your operating system and its vendor-supplied software to prevent them from becoming corrupted. Allows you to create pre-compiled binary installers of ported applications to quickly install software on remote computers without compiling from source code. MacPorts is developed on OS X, though it is designed to be portable so it can work on other Unix-like systems, especially those descended from the Berkeley Software Distribution (BSD). In practice, installing ports only works on OS X. MacPorts base can be compiled on Linux (and possibly other POSIX-compatible systems) where it is mainly used to set up mirrors and generate support files for installations on OS X. The following notational conventions conv entions are are used in the MacPorts Guide to distinguish between terminal input/output, file text, and other special text types. Terminal I/O and I/O and file file text.
$ Commands to be typed into a terminal window. Command output to a terminal window. File text. Other special text types. A hyperlink: spontaneous combustion. combustion . A file: /var/log/system.log. A command: ifconfig . An option: port install
Chapter 2. Installing MacPorts This chapter shows you how to install MacPorts and its prerequisites step-by-step. Note that the section about installing Xcode is Xcode is OS X-specific. If you wish to install MacPorts on another platform, first make sure you have a working C compiler installed, skip ahead to installing MacPorts from source, source , and continue to the end of the chapter.
2.1. Install Xcode Xcode is Xcode is a package provided by Apple containing compilers, libraries and additional tools required to develop applications for OS X.
Note Always make sure to install the latest available version of Xcode for your OS X release; using outdated versions of Xcode may cause port install failures. Also note that Xcode is not updated via OS X's Software Update utility on OS versions prior to 10.6, and is updated via the Mac App Store starting with 10.7.
https://guide.macports.org/#installing.macports.git
Page 1 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Follow the instructions for your version of OS X:
2.1.1. Install Xcode on OS X 10.9 or Later Download the latest version of Xcode from the Apple developer website or website or get it using the Mac App Store. Store . Once you have Xcode installed, open a terminal, run xcode-select --install, and click the Install button to install the required command line developer tools. Don't worry if you see a message telling you the software cannot be installed because it is not currently available from the Software Update Server. This usually means you already have the latest version installed. You can also get the command line tools from the Apple developer website. website .
2.1.2. Install Xcode on OS X 10.7 Lion or OS X 10.8 Mountain Lion Download the latest version of Xcode from the Apple developer website or website or get it using the Mac App Store. Store . 2.1.2.1. Xcode 4.3 and Later
Xcode 4.3 and later do not automatically install the command line tools, but MacPorts requires them. To install them, open the Xcode application, go to the Preferences window, to the Downloads section, and click the Install button next to Command Line Tools. Be sure to return to this window after every Xcode upgrade to ensure that the command line tools are also upgraded. If you wish to create Installer packages packages with port pkg, you will also need to install PackageMaker, which is in the “Auxiliary Tools for Xcode” package as of Xcode 4.3. The download page for this package can be opened via the Xcode -> Open Developer Tool -> More Developer Tools... menu item. After downloading and mounting the disk image, drag the PackageMaker application to your /Applications directory.
2.1.3. Install Xcode on Mac OS X 10.6 Snow Leopard If you are using Mac OS X 10.6, there are two branches of Xcode which could be considered to be the latest, 3.2.x and 4.x. Xcode 4 costs money, but Xcode 3 is still available free of charge. There are two options for downloading it: 1. Xcode 3.2 - smaller download, but you will need to run Software Update after install ing to get the latest version. Note that Apple might at some point discontinue providing these updates via their update servers. 2. Xcode 3.2.6 and iOS SDK 4.3 - includes the iOS SDK which is not needed for MacPorts. Both are available from the Apple developer website. website . You may also be able to install Xcode 3.2 from your Mac OS X 10.6 DVD and then run Software Update to get the latest version. Ensure that those of the following options that are available in the installer for your version of Xcode are selected: UNIX Development System Tools X11 SDK Command Line Support
2.1.4. Install Xcode on Older Releases of Mac OS X If you have an earlier release of Mac OS X, you may download the latest version of Xcode for OS X 10.5 (Xcode 3.0 and Xcode 3.1 Developer Tools) or 10.4 (Xcode 2.4.1 and Xcode 2.5 Developer Tools) from the Apple developer website. website . Ensure that those of the following options that are available in the installer for your version of Xcode are selected: UNIX Development System Tools X11 SDK Command Line Support
2.2. Install MacPorts If you are using OS X, you should install MacPorts using the OS X package installer unless you do not wish to install it to /opt/local/, the default MacPorts location, or if you wish to install a pre-release version of MacPorts base. However, if you wish to install multiple copies of MacPorts MacPorts or or install MacPorts on another OS platform, you must install MacPorts from the source code. code .
2.2.1. OS X Package Install The OS X package installer automatically installs MacPorts, sets the shell environment, environment , and runs a selfupdate operation to update the ports tree and MacPorts base with the latest release. 1. Download the latest MacPorts-2.4.1-....pkg installer from the releases on GitHub. GitHub. Here are direct links for the latest versions of OS X: macOS 10.12 Sierra:
MacPorts-2.4.1-10.12-Sierra.pkg
https://guide.macports.org/#installing.macports.git
Page 2 of 81
MacPorts Guide
22/09/17 8:30 p.m.
OS X 10.11 El Capitan:
MacPorts-2.4.1-10.11-ElCapitan.pkg OS X 10.10 Yosemite:
MacPorts-2.4.1-10.10-Yosemite.pkg OS X 10.9 Mavericks:
MacPorts-2.4.1-10.9-Mavericks.pkg 2. Double-clic k the downloaded package installer to perform the default “easy” install. 3. After this step you are done already, MacPorts is now installed and your shell environment was set up automatically by the installer. To confirm the installation is working as expected, now try using port in a new terminal terminal window.
$ port version Version: 2.4.1 In case of problems such as “command not found”, make sure that you opened a new terminal window or consult Section 2.5, “MacPorts and the Shell”. Shell” . Otherwise, please skip the remainder of this chapter and continue with Chapter 3, Using MacPorts in in this guide.
2.2.2. Source Install If you installed MacPorts using the package installer, skip this section. To install MacPorts from the source code, follow the steps below. 1. Download and extract the MacPorts 2.4.1 tarball. tarball . Either do so using your browser and the Finder, or use the given commands in a terminal window.
$ curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.4.1.tar.bz2 $ tar xf MacPorts-2.4.1.tar.bz2 2. Afterwards, per form the commands shown in the terminal window. If you wish to use a path other than /opt/local, follow the instructions for installing multiple copies of MacPorts instead. MacPorts instead.
$ cd MacPorts-2.4.1/ $ ./configure $ make $ sudo make install 3. Please continue with Section 2.5, “MacPorts and the Shell” to set up your shell environment.
2.2.3. Git Install If you installed MacPorts using the package installer, skip this section. There are times when some may want to run MacPorts from a version newer than the current stable release. Maybe there's a new feature that you'd like to use, or it fixes an issue you've encountered, or you just like to be on the cutting edge. These steps explain how to run completely from master, using only Git to keep MacPorts up to date. Though a distinction is made between pre-release and release versions of MacPorts base, the ports collection supports no such distinction or versioning. The selfupdate selfupdate command command installs the latest ports tree, and updates MacPorts base to the latest released version. 1. Check out MacPorts source Pick a location to store a working copy of the MacPorts code. For this example, /opt/mports will be used, but you can put the source anywhere. This example will create /opt/mports/macports-base containing everything needed for MacPorts.
$ mkdir -p /opt/mports $ cd /opt/mports $ git clone https://github.com/macports/macports-base.git 2. Build and Install MacPorts MacPorts uses autoconf and makefiles for installation. These commands will build and install MacPorts to /opt/local. You can add --prefix to ./configure to relocate MacPorts to another directory if needed.
$ cd /opt/mports/macports-base $ ./configure --enable-readline $ make $ sudo make install $ make distclean 3. (Optional) Configure Configure MacPorts to use port information from Git This step is useful if you want to do port development. Check out the ports tree from git:
$ cd /opt/mports $ git clone https://github.com/macports/macports-ports.git /opt/local/etc/macports/so tc/macports/sources.conf urces.conf in a text editor. The last line should look like this: Then open /opt/local/e
rsync://rsync.macports.org/release/tarballs/ports.tar [default] Change it to point to the working copy you checked out:
https://guide.macports.org/#installing.macports.git
Page 3 of 81
MacPorts Guide
22/09/17 8:30 p.m.
file:///opt/mports/macports-ports [default] 1. Introduction 2. Installing MacPorts 2.1. Install Xcode 2.2. Install MacPorts 2.3. MacPorts Upgrade 2.4. Uninstall 2.5. MacPorts and the Shell
3. Using MacPorts 3.1. The port Command 3.2. Port Variants 3.3. Common Tasks 3.4. Port Binaries
4. Portfile Development 4.1. Portfile Introduction 4.2. Creating a Portfile 4.3. Example Portfiles 4.4. Port Variants 4.5. Patch Files 4.6. Local Portfile Repositories 4.7. Portfile Best Practices 4.8. MacPorts' buildbot
5. Portfile Reference 5.1. Global Keywords 5.2. Global Variable Variables s 5.3. Port Phases 5.4. Dependencies 5.5. Variants 5.6. Tcl Extensions & Useful Tcl Commands 5.7. StartupItems 5.8. Livecheck / Distcheck 5.9. PortGroups
6. MacPorts Internals 6.1. File Hierarchy
Now MacPorts will look for portfiles in the working copy and use Git instead of rsync to update your ports tree. 4. Environment You should setup your PATH and other environment options according to Section 2.5, “MacPorts and the Shell”. Shell” .
2.2.4. Install Multiple MacPorts Copies Occasionally a MacPorts developer may wish to install more than one MacPorts instance on the same host. Only one copy of MacPorts may use the default prefix /opt/local, so for additional installations installations use the option --prefix as shown below. It's also recommended to change the applications dir using --with-applications-dir to avoid conflicts in /Applications/MacPorts.
Note The first command temporarily removes the standard MacPorts binary paths because they must not be present while installing a second instance.
$ export PATH=/bin:/sbin:/usr/bin:/usr/sbin $ MP_PREFIX=/opt/macpor ts-test $ ./configure --prefix=$MP_PREFIX --with-applications-dir=$MP_PREFIX/Applications $ make $ sudo make install After installing the second instance you might need to add
startupitem_install no $MP_PREFIX/etc/macports/ma tc/macports/macports.conf cports.conf to avoid conflicts in /Library/LaunchAgents. to $MP_PREFIX/e
2.3. MacPorts Upgrade MacPorts base upgrades are performed automatically (when a newer release is available) during a selfupdate selfupdate operation. operation. To upgrade a copy of MacPorts that was installed from source to the newer release of the source code, simply repeat the source install with install with the newer version of the MacPorts source code.
2.4. Uninstall Uninstalling MacPorts can be a drastic step, and depending on the issue you are experiencing, you may not need to do so. If you are unsure, ask on the macports-users mailing list first. If you need to uninstall MacPorts, and port is functioning, first uninstall all the installed ports by running this command in the Terminal:
$ sudo port -fp uninstall installed All that will be left in your installation prefix now will be files that were not registered to any port. This includes configuration files, databases, any files which MacPorts renamed in order to allow a forced installation or upgrade, and the base MacPorts software itself. You may wish to save your configuration files (most are in $prefix/etc), databases, or any other unique data by moving it aside. To remove all remaining traces of MacPorts, run the following command in the Terminal. If you have changed prefix , applications_dir or frameworks_dir from their default values, then replace /opt/local with your prefix, replace /Applications/MacPorts with your applications_dir, and/or add your frameworks_dir to the list, respectively.
$ sudo rm -rf \ /opt/local \ /Applications/DarwinPo rts \ /Applications/MacPorts \ /Library/LaunchDaemons /org.macports.* \ /Library/Receipts/Darw inPorts*.pkg \ /Library/Receipts/MacP orts*.pkg \ /Library/StartupItems/ DarwinPortsStartup \ /Library/Tcl/darwinpor ts1.0 \ /Library/Tcl/macports1 .0 \ ~/.macports If you use a shell other than bash (perhaps tcsh), you may need to adjust the above to fit your shell's syntax. Also note that depending on which version of MacPorts you have and which ports you have installed, not all of the above paths will exist on your system. This is OK.
2.5. MacPorts and the Shell MacPorts requires that some environment variables be set in the shell. When MacPorts is installed using the OS X package installer, a “postflight” script is run after installation that automatically adds or modifies a shell configuration file in your home directory, ensuring that it defines variables according to the rules described in the following section. Those installing MacPorts
https://guide.macports.org/#installing.macports.git
Page 4 of 81
MacPorts Guide
22/09/17 8:30 p.m.
from source code must modify their environment manually using the rules as a guide. Depending on your shell and which configuration files already exist, the installer may use .profile, .bash_login, .bash_profile, .tcshrc, or .cshrc.
2.5.1. The Postflight Script The postflight script automatically sets the PATH variable, and optionally the MANPATH and DISPLAY variables according to the rules described below. If a current shell configuration file exists at installation time it is renamed to “mpsaved_$timestamp”. Those installing MacPorts from source code must modify their environment manually using the rules as a guide. Required: PATH variable This variable is set by the postflight script to prepend the MacPorts executable paths to the current path as shown. This puts the MacPorts paths at the front of PATH so that the MacPorts binaries will take precedence over vendorsupplied binaries.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
Note The user environment's $PATH is not in effect while ports are being installed, because the $PATH is scrubbed before ports are installed, and restored afterwards. To change the search path for locating system executables (rsync, tar, etc.) during port installation, see the macports.conf file variable binpath. But changing this variable is for advanced users only, and is not generally needed or recommended.
Optional: MANPATH variable Condition: If prior to MacPorts installation a MANPATH variable exists in a current .profile that contains neither the value ${prefix}/share/man, nor any empty values, the postflight script sets the MANPATH variable as shown below. Otherwise, the MANPATH variable is omitted.
export MANPATH=/opt/local/share/man:$MANPATH Here are some examples of paths that contain empty values: /usr/share/man: :/usr/share/man /usr/share/man::/usr/X11R6/man Optional: DISPLAY variable Condition: If installing on a Mac OS X version earlier than 10.5 (Leopard), and if a shell configuration file exists at time of MacPorts installation without a DISPLAY variable, the postflight script sets a DISPLAY variable as shown below. The DISPLAY variable is always omitted on Mac OS X 10.5 or higher.
export DISPLAY=:0.0
2.5.2. Verify the Configuration File To verify that the file containing the MacPorts variables is in effect, type env in the terminal to verify the current environment settings after the file has been created. Example output for env is shown below.
Note Changes to shell configuration files do not take effect until a new terminal session is opened.
MANPATH= TERM_PROGRAM=Apple_Terminal TERM=xterm-color SHELL=/bin/bash TERM_PROGRAM_VERSION=237 USER=joebob __CF_USER_TEXT_ENCODING =0x1FC:0:0 PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin PWD=/Users/joebob EDITOR=/usr/bin/pico SHLVL=1 HOME=/Users/joebob LOGNAME=joebob DISPLAY=:0.0 SECURITYSESSIONID=b0cea0 _=/usr/bin/env
https://guide.macports.org/#installing.macports.git
Page 5 of 81
MacPorts Guide
22/09/17 8:30 p.m.
2.5.3. Optional Editor Variables You can set an environment variable in order to use your favorite text editor with the port edit command. MacPorts will check MP_EDITOR, VISUAL and EDITOR in this order, allowing you to either use a default editor shared with other programs (VISUAL and EDITOR) or a MacPorts-specific one ( MP_EDITOR). For example, to use the nano editor, add this line to your bash config:
export EDITOR=/usr/bin/nano To use the user-friendly GUI editor BBEdit (installation required), add this line:
export EDITOR=/Applications/BBEdit.app/Contents/Helpers/bbedit_tool To keep a command-line text editor as default while using BBEdit with portfiles, add this:
export EDITOR=/usr/bin/vi export MP_EDITOR=/Applications/BBEdit.app/Contents/Helpers/bbedit_tool
Chapter 3. Using MacPorts This chapter describes using port, port variants, common tasks and port binaries.
3.1. The port Command port is the main utility used to interact with MacPorts. It is used to update Portfiles and the MacPorts infrastructure, and install and manage ports.
3.1.1. port help The help action shows some brief information about the specified action, or if no action is specified, shows basic usage information for port in general.
$ port help selfupdate Usage: selfupdate --nosync Upgrade MacPorts itself and run the sync target --nosync
Do not run the sync target, i.e., do not update the ports tree. Only checks for (and installs, if available) new versions of MacPorts.
3.1.2. port selfupdate The selfupdate action should be used regularly to update the local ports tree with the global MacPorts ports repository so you will have the latest versions of software packages available. It also checks for new releases of MacPorts itself, and upgrades it when necessary.
$ sudo port selfupdate ---> Updating MacPorts base MacPorts base ---> Updating ---> MacPorts
MacPorts base sources using rsync version 2.4.1 installed, version 2.4.1 downloaded. the ports tree base is already the latest version
If selfupdate detects that a newer version of MacPorts is available, it automatically updates the installed copy of MacPorts base to the latest released version. In that case, you will see this message:
---> Updating MacPorts base sources using rsync MacPorts base version 2.4.0 installed, MacPorts base version 2.4.1 downloaded. ---> Updating the ports tree ---> MacPorts base is outdated, installing new version 2.4.1 Installing new MacPorts release in /opt/local as root:admin; permissions 755 If the selfupdate procedure fails you'll see a message like this:
Error installing new MacPorts base: command execution failed As always, you can use the debug flag -d to enable verbose output. If your selfupdate failed, re-run it with debug output enabled to see all output generated by the build system.
$ sudo port -d selfupdate The output may give you an idea why the build failed. Look for the first occurrences of “error”. If you cannot figure out what's wrong yourself, feel free to ask on the
mailing list and attach the output generated by sudo port -d selfupdate.
https://guide.macports.org/#installing.macports.git
Page 6 of 81
MacPorts Guide
22/09/17 8:30 p.m.
selfupdate accepts a single switch: --nosync Only update MacPorts itself, do not update the tree of Portfiles.
3.1.3. port sync The sync action performs a subset of selfupdate. It synchronizes the ports tree, as does selfupdate, but it does not check for MacPorts upgrades. On OS X, unless there is a special reason not to do so, run selfupdate instead.
sync does not accept any switches.
3.1.4. port diagnose The diagnose action checks for common issues in the user's environment and reports all issues it finds to the user, along with possible fixes for said problem.
diagnose accepts a single switch: --quiet Only displays warnings and errors, rather than the status of all tests run.
Note This command will only be available in MacPorts version 2.4 and above.
3.1.5. port reclaim The reclaim action attempts to reclaim space by uninstalling inactive ports, and removing unnecessary files that were downloaded during the installation process.
reclaim does not accept any switches.
Note This command will only be available in MacPorts version 2.4 and above.
3.1.6. port list The list action lists the currently available version of the specified ports, or if no ports are specified, displays a list of all available ports. The list of available ports is very long, so use search if you are looking for a specific port.
$ port list
Note port list always lists the most recent version available in MacPorts, which is not necessarily the version you have installed. For this reason, port list installed likely produces unexpected output. In most cases where you would list, using installed or echo is the better choice instead. Both port installed and port echo installed would produce the output you might expect from the command, port list installed will not (and, to make matters worse, will be slow).
You will hardly need port list at all to work with MacPorts. When searching, port search is the better choice and when trying to list ports, port installed and port echo are much more useful.
3.1.7. port search The search action allows finding ports by partial matches of the name or description. Other fields can be matched against, and matched in different ways, by using options. port search is the tool of choice if you are looking for a specific software in MacPorts. We recommend you read up on some of its flags to improve your efficiency when searching for ports. Run port help search for an exhaustive list of possible switches. Suppose you are looking for PHP in MacPorts. You might start with port search php and notice your query produces a lot of output. In fact, at the time of writing this, this search produces 661 matches. By default, port search searches both name and description of a port. While we're looking for PHP, we can reduce the number of hits by using the --name flag. Furthermore, we only want ports whose name starts with “php”, so we add the --glob flag (actually, we could leave it out because it is the default) and modify the search term to php*:
$ port search --name --glob 'php*' Furthermore, we can enable compact output by using the --line switch. This causes only a single line to be printed for each match:
$ port search --name --line --glob 'php*'
https://guide.macports.org/#installing.macports.git
Page 7 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Among a large number of PHP modules you will find the main PHP ports, which are named php . Choose one to install. If you know regex and know about the format of the PHP versions, you can further reduce the output of port search:
$ port search --name --line --regex '^php\d*$' php php4 php5 php52 php53 php54 php55 php56
5.5 4.4.9 5.3.28 5.2.17 5.3.28 5.4.31 5.5.15 5.6.0RC2
lang lang lang lang lang lang lang lang
www www www www www www www www
PHP: PHP: PHP: PHP: PHP: PHP: PHP: PHP:
Hypertext Hypertext Hypertext Hypertext Hypertext Hypertext Hypertext Hypertext
Preprocessor Preprocessor Preprocessor Preprocessor Preprocessor Preprocessor Preprocessor Preprocessor
Let us look at another example that is less complicated. Assuming you are looking for rrdtool, a popular system to store and graph time-series data, the simple search approach works well:
$ port search rrd cacti @0.8.8b (net) Cacti is a complete RRDtool network graphing solution. jrrd @1.0.4 (java) Java interface to RRDTool netmrg @0.20 (net) An RRDtool frontend for network monitoring, reporting, and graphing that generat MRTG style graphs. network-weathermap @0.97c (net) Weathermap is a network visualisation tool, to take graphs you already have and overview of your network as a map. It supports RRD, MRTG (RRD and old log-format tab-delimited text files. Other sources are via plugins or external scripts. php-rrd @1.1.3 (php, net, devel) PHP rrdtool extension php5-rrd @1.1.3 (php, net, devel) PHP rrdtool extension php5-rrdtool @1.0.5 (php, net, devel) this port is only a stub and has been made obsolete by php5-rrd php53-rrd @1.1.3 (php, net, devel) PHP rrdtool extension php54-rrd @1.1.3 (php, net, devel) PHP rrdtool extension php55-rrd @1.1.3 (php, net, devel) PHP rrdtool extension rrdtool @1.4.7_5 (net) Round Robin Database Found 11 ports. The possible switches to search and their meaning are:
--case-sensitive Match the search string in a case-sensitive manner.
--exact Match the literal search string exactly.
--glob Treat the given search string as glob search string (i.e., expand wildcards *, ?, and [chars]). This is the default behavior.
--regex Treat the given search string as regular expression.
-- Test the search string against . Can be specified multiple times to test against multiple fields. The default is -name --description. Possible values for are
--category, --categories Search for ports in a given category.
--depends, --depends_build, --depends_extract, --depends_fetch, --depends_lib, --depends_run
https://guide.macports.org/#installing.macports.git
Page 8 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Search for ports that depend on the port given as search string. The --depends is an alias for all other - options combined. Note that only dependencies specified in default variants will be found. depends_
--description, --long_description Test the search string against ports' descriptions.
--homepage Test the search string against the homepage field of all ports.
--maintainer, --maintainers Search for ports maintained by a specific maintainer.
--name Search only ports' names.
--portdir Test the search string against the path of the directory that contains the port.
--variant, --variants Search for variant names.
3.1.8. port info The info action is used to get information about a port: name, version, description, variants, homepage, dependencies, license, and maintainers.
$ port info yubico-pam yubico-pam @2.16 (security) Variants: universal Description:
Homepage:
The Yubico PAM module provides an easy way to integrate the Yu existing user authentication infrastructure. The module can be validate YubiKeys against Yubico's YubiCloud infrastructure, a validation server or it can be used for offline authentication YubiKeys supporting a challenge-response protocol. https://github.com/Yubico/yubico-pam
Build Dependencies: Library Dependencies: Platforms: License: Maintainers:
pkgconfig, autoconf, automake, libtool ykpers, yubico-c-client darwin BSD [email protected]
3.1.9. port deps The deps action lists the dependencies of a port. Dependencies are the packages are required by a port at runtime (library and runtime dependencies) or required to install it (build, fetch, and extract dependencies).
$ port deps apache2 Full Name: apache2 @2.2.27_0+preforkmpm Library Dependencies: apr, apr-util, expat, openssl, pcre, perl5, zlib Note that the list of dependencies might depend on the variants you chose. For example, choosing the +openldap variant of apache2 adds a dependency on openldap:
$ port deps apache2 +openldap Full Name: apache2 @2.2.27_0+openldap+preforkmpm Library Dependencies: apr, apr-util, expat, openssl, pcre, perl5, zlib, openldap deps accepts two switches: --index Do not read the Portfile to determine dependencies. Instead, rely on the information cached in the port index. Note that (despite specifying them), this option will ignore any effects of variants. It is, however, much faster.
--no-build Exclude dependencies only required at build time, i.e., fetch, extract, and build dependencies.
3.1.10. port variants The variants action allows you to check what variations of a port are available before you install it. Variants are a way for port authors to provide options you can use to customize your build at install time. See Invoking Port Variants below to install ports that have variants.
$ port variants apache2 +universal apache2 has the variants: eventmpm: Use event MPM (experimental) * conflicts with preforkmpm workermpm openldap: Enable LDAP support through OpenLDAP
https://guide.macports.org/#installing.macports.git
Page 9 of 81
MacPorts Guide
22/09/17 8:30 p.m.
[+]preforkmpm: Use prefork MPM * conflicts with eventmpm workermpm +universal: Build for multiple architectures workermpm: Use worker MPM * conflicts with eventmpm preforkmpm This output lists all variants followed by their description. If a variant depends on or conflicts with other variants, a line detailing that follows. A variant name prefixed by + indicates that it has been enabled (on the command line), while a prefix indicates that it has been disabled. When bracketed, a prefix + means that the variant is enabled by default. Any [] are derived from the Portfile. While () are derived from the variants.conf. See Section 6.2.3, “variants.conf” for more information on variants.conf.
3.1.11. port install The action install is used to install a port. Once you determined the name of a port you want (possibly using port search), you can install it using this command. See Section 3.2.1, “Invoking Variants” on how to choose variants when installing a new port. For example,
$ sudo port install apache2 -preforkmpm +workermpm installs the apache2 port without the preforkmpm , but with the workermpm variant. If the installation of a port fails, you can enable verbose or debug output by giving the -v or -d flag to port:
$ sudo port -v install apache2 All debug information is also kept in main.log for the port you installed. Its path will be printed automatically if the installation fails. You can manually get the path using port logfile . Note that logfiles will automatically be deleted on successful installation. If the installation of a port fails, you should always clean and try again, i.e., run
$ sudo port clean and re-execute the command you ran before. You might also want to try enabling trace mode, which can prevent conflicts caused by files installed by other ports or in common system locations, such as /usr/local. To do that, re-run the installation with the -t flag, i.e.,
$ sudo port -t install If the port still fails to install after you have followed these steps, please file a ticket and attach the main.log of a clean attempt.
Note The installation of a single port consists of multiple phases. These phases are fetch, extract, patch, configure, build, destroot, archive, and finally install. You may break up a port's installation into smaller steps for troubleshooting by using the name of one of these phases as action rather than install. For example
$ sudo port destroot apache2 will run the installation of apache2 until the destroot phase. See Section 5.3, “Port Phases” for a complete list of phases and a detailed description.
install takes the following switches: --no-rev-upgrade By default, a binary sanity check called rev-upgrade is run automatically after each successful installation. Pass this flag, if you want to avoid running this step, for example if you want to run it explicitly later after a number of installations using sudo port rev-upgrade, or if you know it will detect problems but want to defer dealing with them.
--unrequested By default, each port you install using the install explicitly (contrary to ports installed as a dependency of a different port) is marked as “requested”. If you want MacPorts to treat a port you installed manually as if it was automatically installed as a dependency (e.g., if a dependency failed to build and you re-tried installing the dependency only), pass this flag.
3.1.12. port clean The action clean deletes intermediate files created by MacPorts while installing a port. A port clean is often necessary when builds fail and should be the first thing to try after a failed installation attempt.
$ sudo port clean port clean can also be used to remove corrupted downloads after a failed fetch phase, by specifying the --dist flag:
$ sudo port clean --dist deletes all files that have been downloaded for the given port.
clean accepts the following options:
https://guide.macports.org/#installing.macports.git
Page 10 of 81
MacPorts Guide
22/09/17 8:30 p.m.
--archive Remove temporary archives.
--dist Remove downloaded files.
--logs Remove log files.
--work Remove the work directory, i.e., the directory used by MacPorts to build a software. This removes all traces of an attempted build and is the default operation.
--all All of the above combined.
3.1.13. port uninstall The uninstall action will remove an installed port. It is one of the actions you will use fairly often in MacPorts.
$ sudo port uninstall MacPorts will refuse to uninstall ports that are still needed by other ports. For example:
$ sudo port uninstall libcomerr ---> Unable to uninstall libcomerr @1.42.9_0, the following ports depend on it: ---> kerberos5 @1.11.3_0 ---> subversion @1.8.9_0 ---> subversion-perlbinding s-5.16 @1.8.9_0 Error: port uninstall failed: Please uninstall the ports that depend on libcomerr fi You can recursively uninstall all ports that depend on the given port before uninstalling the port itself to work around this. To do that, use the --follow-dependents flag.
$ sudo port uninstall --follow-dependents libcomerr You can also override this safety check using the -f (force) flag. Since this will obviously break the dependents you shouldn't do this unless you know what you are doing.
$ sudo port -f uninstall libcomerr Uninstalling a port will not uninstall ports that have been automatically installed as dependencies of the uninstalled port and are otherwise unused. You can trigger this behavior by passing the --follow-dependencies flag. Ports that were manually installed (i.e., are marked as “requested”) or have other dependents will not be removed. You can manually uninstall the unneeded ports later using the leaves pseudo-port, e.g., using sudo port uninstall leaves .
uninstall supports the following switches: --follow-dependents Recursively uninstall ports that depend on the specified port before uninstalling the port itself. See also the textual description above.
--follow-dependencies Also uninstall ports that were automatically installed as dependencies of the removed port and are no longer needed.
--no-exec Avoid running any uninstall hooks, such as commands that update cache files.
3.1.14. port contents The contents action displays a list of all files that have been installed by a given port. You can only use contents for ports you installed.
$ port contents xorg-renderproto Port xorg-renderproto contains: /opt/local/include/X11/extensions/render.h /opt/local/include/X11/extensions/renderproto.h /opt/local/lib/pkgconfig/renderproto.pc /opt/local/share/doc/renderproto/renderproto.txt Common uses for contents are finding the location of a port's executable after installing it. The following line is usually helpful in this case:
$ port -q contents | grep -E '/s?bin/' The -q (quiet) flag suppresses the header line in this case, but is not strictly necessary.
contents accepts: --size Prints a human-readable representation of the files' sizes.
--units UNIT
https://guide.macports.org/#installing.macports.git
Page 11 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Used in conjunction with --size to choose the unit of the file size. Valid parameters for UNIT are
B List sizes in bytes.
K, Ki, or KiB List sizes in KiB, i.e., 1024 bytes.
Mi, or MiB List sizes in MiB, i.e., 1024 * 1024 bytes.
Gi, or GiB List sizes in GiB, i.e., 1024 * 1024 * 1024 bytes.
k, or kB List sizes in kB, i.e., 1000 bytes.
M , or MB List sizes in MB, i.e., 1000 * 1000 bytes.
G, or GB List sizes in GB, i.e., 1000 * 1000 * 1000 bytes.
3.1.15. port installed The installed action displays the installed versions and variants of the specified ports, or if no ports are specified, all installed ports. It also displays whether a port is “active”, i.e., whether the files belonging to this port are currently present on disk or inactive, i.e., stashed away in a compressed tarball.
$ port installed The following ports are currently installed: a52dec @0.7.4_0 (active) adns @1.4_0 (active) apache2 @2.2.27_0+preforkmpm (active) apr @1.5.1_0 (active) apr-util @1.5.3_0 (active) aquaterm @1.1.1_0 (active) asciidoc @8.6.9_1+python27 (active) … XviD @1.3.3_0 (active) xz @5.0.5_0 (active) yasm @1.2.0_0 (active) ykpers @1.12.0_0 (active) youtube-dl @2014.07.25.1_0+pytho n27 (active) yubico-c-client @2.12_0 (active) yubico-pam @2.16_0 (active) zlib @1.2.8_0 (active) Use -v to also display the platform and CPU architecture(s) for which the ports were built, and any variants which were explicitly negated.
$ port -v installed libsdl The following ports are currently installed: libsdl @1.2.15_3-x11 (active) platform='darwin 13' archs='x86_64'
3.1.16. port outdated The outdated action checks your installed ports against the current ports tree to see they have been updated since you installed them. Note that you will only get new versions by updating your ports tree using selfupdate (or sync).
$ port outdated The following installed ports are outdated: gnupg 1.4.16_0 < 1.4.18_0 gnupg2 2.0.22_2 < 2.0.25_0 gpg-agent 2.0.22_1 < 2.0.25_0 gpgme 1.5.0_0 < 1.5.1_0 HexFiend 2.1.2_1 < 2.3.0_0 libksba 1.0.8_0 < 1.3.0_0 p5.16-class-methodmaker 2.180.0_1 < 2.210.0_0 p5.16-gnupg-interface 0.330.0_3 < 0.500.0_1 p5.16-ipc-run 0.910.0_1 < 0.920.0_0 port outdated lists the ports for which an upgrade is available and on the second column, why MacPorts thinks the port needs an upgrade. In most cases, this will be an increase in the version number. If it isn't, more details will be given.
3.1.17. port upgrade The upgrade action upgrades installed ports and their dependencies to the latest version available in MacPorts. In most cases, you will run
https://guide.macports.org/#installing.macports.git
Page 12 of 81
MacPorts Guide
22/09/17 8:30 p.m.
$ sudo port upgrade outdated to update all ports that have an upgrade available. You can, however, selectively upgrade ports if you want to delay other upgrades until later. This is not recommended unless you know what you are doing, since you might experience software errors for the ports that have not yet been upgraded. To upgrade individual ports, specify the name(s) of the port(s) to upgrade:
$ sudo port upgrade gnupg2 Note that MacPorts may decide to upgrade other dependent ports before upgrading the port you requested to be updated. Do not attempt to prevent this, since it will very likely lead to problems later.
Note upgrade does not uninstall the old version of a port. Instead, it deactivates it, i.e., it stashes the files belonging to the older version away in a tarball. This allows you to go back to the older version if there happens to be a problem with the updated one. To do that, run
$ port installed to determine the version number of the old version you want to re-activate, and run
$ sudo port activate @ to go back to the old version. If you do not want to keep the old versions around while upgrading, you can pass -u when upgrading:
$ sudo port -u upgrade outdated However, we instead recommend keeping the older versions around for a while and running
$ sudo port uninstall inactive once in a while.
upgrade accepts a number of switches: --force Always consider the given ports outdated, regardless of whether they actually are.
--enforce-variants If the installed variants do not match those requested, upgrade (and change variants) even if the port is not outdated. You can use this to switch the variant selection on an installed port, e.g., using
$ sudo port upgrade --enforce-variants apache2 -preforkmpm +workermpm Note that --enforce-variants will also enforce your variant selection in all dependencies. If you know this is not necessary, you can avoid processing dependencies using the global -n flag:
$ sudo port -n upgrade --enforce-variants apache2 -preforkmpm +workermpm --no-replace Do not automatically install replacement ports for a port that you have installed, but was replaced with a different one.
3.1.18. port dependents The dependents action reports what ports depend upon a given (installed) port, if any.
$ port dependents openssl apache2 depends on openssl curl depends on openssl cyrus-sasl2 depends on openssl git depends on openssl kerberos5 depends on openssl lftp depends on openssl libssh depends on openssl mosh depends on openssl openldap depends on openssl p5.16-net-ssleay depends on openssl python27 depends on openssl python32 depends on openssl qt4-mac depends on openssl ruby19 depends on openssl serf1 depends on openssl textmate2 depends on openssl wireshark depends on op enssl Note that dependents does not work for ports that are not installed on your system. If you want to find out, which ports depend on a port that you have not installed, you can use
$ port echo depends:
https://guide.macports.org/#installing.macports.git
Page 13 of 81
MacPorts Guide
22/09/17 8:30 p.m.
This command will, however, not cover dependencies that are only present in non-default variants.
3.1.19. port livecheck The livecheck action checks to see if the application corresponding to a given port has been updated at the developer's download site. This action is mostly useful for port maintainers to determine whether their port needs to be updated, but other may also wish to see if a port packages the latest available version. See Section 5.8, “Livecheck / Distcheck” for more information on livecheck.
$ port livecheck rb19-sass rb19-sass seems to have been updated (port version: 3.3.10, new version: 3.3.14)
Note If livecheck finds no higher version at the port's download site, it prints nothing. The option -d (debug) may be used for detailed livecheck processing information.
3.1.20. port lint The lint action checks if the Portfile conforms to the MacPorts standards specified in Portfile Development. You should use this if you modified a Portfile before submitting patches back to MacPorts. If a Portfile validates fine the following message is shown.
$ port lint rb19-sass ---> --->
Verifying Portfile for rb19-sass 0 errors and 0 warnings found.
Otherwise the warnings and errors are listed.
$ port lint abiword ---> Verifying Portfile for abiword Warning: Variant use_binary does not have a description Warning: Variant use_source does not have a description Warning: no license set ---> 0 errors and 3 warnings found. lint has the following flag: --nitpick Enables additional checks that are mostly whitespace-related and best practices.
3.2. Port Variants Variants are a way for port authors to provide options for a port that may be chosen at installation. Typically, variants are optional features that can be enabled, but are not necessarily useful for all users and are thus not enabled by default. To display the available variants for a port, if any, use this command:
$ port variants For example:
$ port variants apache2 apache2 has the variants: eventmpm: Use event MPM (experimental) * conflicts with preforkmpm workermpm openldap: Enable LDAP support through OpenLDAP [+]preforkmpm: Use prefork MPM * conflicts with eventmpm workermpm universal: Build for multiple architectures workermpm: Use worker MPM * conflicts with eventmpm preforkmpm This output lists all variants followed by their description. If a variant depends on or conflicts with other variants, a line with the details on that follows. Variant lines that have a + are enabled and those with - are disabled. Any [] are derived from the Portfile. While () are derived from the variants.conf. See Section 6.2.3, “variants.conf” for more information on variants.conf.
3.2.1. Invoking Variants A variant can only be selected when a port is installed. After you have determined what variants a given port has, if any, you may install a port using a variant by specifying its name preceded by a plus sign on the command line, for example
$ sudo port install apache2 +openldap Multiple variants can be selected by simply listing them one after another separated by a space.
$ sudo port install apache2 +openldap +universal https://guide.macports.org/#installing.macports.git
Page 14 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Use a minus sign to deselect a variant that is on by default.
$ sudo port install apache2 -preforkmpm +workermpm Note that you will not see any confirmation of successful variant selection and MacPorts will not warn you if you misspelled a variant's name. If your installation is successful, but the chosen feature still seems to be missing, check for possible typos. You can use port installed to verify that the port has been installed with the chosen variant. This happens because MacPorts will also use the specified variants for any dependencies. For example,
$ sudo port install apache2 +mariadb is accepted even though apache2 does not have a +mariadb variant. However, it depends on the apr-util port which does have the +mariadb variant and will be installed with it. MacPorts will remember the variants that were used when installing a port. If you upgrade a port later, the same variants will be used, unless you manually specify different variants.
3.2.2. Negating Default Variants A Portfile can specify a default set of variants that will be used when you do not manually override it. Not all ports specify default variants – if there are no default variants, no variants are chosen by default. If you wish to disable a variant that has been enabled by default, either by the Portfile, or by your configuration in variants.conf, you can negate the variant in question by prefixing the variant name with a minus on the command line:
$ sudo port install apache2 -preformmpm +workermpm
3.3. Common Tasks This section lists common operations you may want to perform when managing a MacPorts installation. These are the workflows you will need most while using MacPorts. We recommend you read at least this section as a primer into how to use MacPorts. More details about the usage can be found in Section 3.1, “The port Command” and the port(1) manpage available by running man 1 port in a Terminal. Mind the “sudo” for some of the subsequent examples, which is necessary if you have a default MacPorts installation.
3.3.1. Updating Your Ports Tree The local ports tree is a collection of files that contain information on which packages are available through MacPorts and how they can be installed. You should regularly update your ports tree to get access to updated versions of software and bug fixes. To do that, use selfupdate:
$ sudo port selfupdate Password: ---> Updating MacPorts base MacPorts base ---> Updating ---> MacPorts
MacPorts base sources using rsync version 2.4.1 installed, version 2.4.1 downloaded. the ports tree base is already the latest version
The ports tree has been updated. To upgrade your installed ports, you should run port upgrade outdated
3.3.2. Show Ports Which Need Updating To see what's new after running selfupdate, you can use port outdated to generate a list of ports that have newer versions available. This can help in estimating the time required for sudo port upgrade outdated , even though this depends on further factors such as binary package availability and a port's build time.
$ port outdated The following installed ports are outdated: gnupg 1.4.16_0 < 1.4.18_0 gnupg2 2.0.22_2 < 2.0.25_0 gpg-agent 2.0.22_1 < 2.0.25_0 gpgme 1.5.0_0 < 1.5.1_0 HexFiend 2.1.2_1 < 2.3.0_0 libksba 1.0.8_0 < 1.3.0_0 p5.16-class-methodmaker 2.180.0_1 < 2.210.0_0 p5.16-gnupg-interface 0.330.0_3 < 0.500.0_1 p5.16-ipc-run 0.910.0_1 < 0.920.0_0
3.3.3. Upgrading Outdated Ports To upgrade all your installed and outdated ports, run
$ sudo port upgrade outdated In case you want to upgrade only a specific port (not recommended unless you know what you are doing), replace “outdated” in the command given above with the port's name:
https://guide.macports.org/#installing.macports.git
Page 15 of 81
MacPorts Guide
22/09/17 8:30 p.m.
$ sudo port upgrade makedepend Password: ---> Computing dependencies for makedepend ---> Fetching makedepend ---> Attempting to fetch makedepend-1.0.3.tar.bz2 from http://lil.fr.distfiles.macpo ---> Verifying checksum(s) for makedepend ---> Extracting makedepend ---> Configuring makedepend ---> Building makedepend ---> Staging makedepend into destroot ---> Computing dependencies for makedepend ---> Installing makedepend @1.0.3_0 ---> Deactivating makedepend @1.0.2_0 ---> Activating makedepend @1.0.3_0 ---> Cleaning makedepend Note that MacPorts will upgrade any dependencies of a port first before updating the port itself. So even if you request the update of a single port only, other ports may be upgraded first because they are in the dependency tree. Do not try to avoid this, as it will very likely lead to problems later on – the new version of the port you want to upgrade might require the newer dependency, or it might only have been upgraded at all to be rebuilt against the updated dependency, in which case avoiding the update of the dependency defeats the purpose of the reinstallation.
3.3.4. Removing Inactive Version(s) of Upgraded Port(s) By default, upgrading ports in MacPorts does not remove the older versions. This is a safety measure to ensure you can go back to a working and tested version in case an update goes wrong. To save disk space, you should periodically uninstall any old versions you no longer need. Use
$ port installed inactive to get a list of inactive ports you likely no longer need.
The following ports are currently installed: gnupg @1.4.16_0 gnupg2 @2.0.22_2 gpg-agent @2.0.22_1 gpgme @1.5.0_0 HexFiend @2.1.2_1 libksba @1.0.8_0 p5.16-class-methodmak er @2.180.0_1 p5.16-gnupg-interface @0.330.0_3 p5.16-ipc-run @0.910.0_1 Check the list for any ports you might still want to keep. To remove all of them at once, run
$ sudo port uninstall inactive Password: ---> Uninstalling p5.16-gnupg-interface @0.330.0_3 ---> Cleaning p5.16-gnupg-interface ---> Uninstalling gnupg @1.4.16_0 ---> Cleaning gnupg ---> Uninstalling gpgme @1.5.0_0 ---> Cleaning gpgme ---> Uninstalling gnupg2 @2.0.22_2 ---> Cleaning gnupg2 ---> Uninstalling gpg-agent @2.0.22_1 ---> Cleaning gpg-agent ---> Uninstalling HexFiend @2.1.2_1 ---> Cleaning HexFiend ---> Uninstalling libksba @1.0.8_0 ---> Cleaning libksba ---> Uninstalling p5.16-class-methodmaker @2.180.0_1 ---> Cleaning p5.16-class-methodmaker ---> Uninstalling p5.16-ipc-run @0.910.0_1 ---> Cleaning p5.16-ipc-run Of course you could also select only a specific inactive port, but that requires to specify the exact version:
$ sudo port uninstall HexFiend @2.1.2_1 Password: ---> Uninstalling HexFiend @2.1.2_1 ---> Cleaning HexFiend To uninstall all inactive ports but a single one, you can use the following shortcut:
$ sudo port uninstall inactive and not
3.3.5. Finding Ports Depending on a Certain Port
https://guide.macports.org/#installing.macports.git
Page 16 of 81
MacPorts Guide
22/09/17 8:30 p.m.
If you want to find all ports that depend on a given other port, you can use
$ port echo depends: If you are only interested in the dependent ports that you actually have installed, you can use the quicker and more accurate dependents:
$ port dependents $ port dependents libksba gnupg2 depends on libksba gpg-agent depends on libksba MacPorts also has a recursive version of the dependents action called rdependents:
$ port rdependents libksba The following ports are dependent on libksba: gnupg2 gpgme gpg-agent Finally, to find out which port you manually installed caused the automatic installation of a dependency, use the following expression:
$ port installed requested and rdependentof: $ port installed requested and rdependentof:libksba The following ports are currently installed: gnupg2 @2.0.25_0 (active)
3.3.6. Finding Leaves After a while of using MacPorts, installing and uninstalling ports, packages that have been automatically installed as dependencies for other ports are left behind, even though they are no longer necessary. Ports that have not been manually installed (“requested”) and do not have any dependents are called “leaves” and can be identified using the leaves pseudoport, for example in conjunction with the echo or installed action.
$ port echo leaves git-flow gmake gpgme hs-download-curl pkgconfig py27-docutils python32 texi2html yasm
@0.4.1_2 @4.0_0 @1.5.1_0 @0.1.4_0 @0.28_0 @0.12_0 @3.2.5_0 @5.0_1 @1.2.0_0
These leaves may be wanted, but are in most cases unneeded. See Section 3.3.7, “Keep Your Installation Lean by Defining Leaves as Requested Ports” to find out how to mark some of the leaves as requested. You can uninstall all leaves using
$ sudo port uninstall leaves Note that the uninstallation can cause new ports to become leaves. To uninstall all leaves, you would have to repeat the process until port echo leaves comes back empty. To automate this, you can use --follow-dependencies when uninstalling.
$ sudo port uninstall --follow-dependencies leaves To go through this process interactively so you can make sure you're not uninstalling anything you want to keep, you can install the port_cutleaves port. After installation, run it with
$ sudo port_cutleaves
3.3.7. Keep Your Installation Lean by Defining Leaves as Requested Ports Well, before we come to the procedure of defining your requested ports, let's have a look at a typical scenario where you want to understand what is actually installed and what is on the other hand truly necessary for your system. Say checking leaves of your MacPorts installation gives this output:
$ port echo leaves git-flow gmake gpgme hs-download-curl pkgconfig py27-docutils python32 texi2html yasm
@0.4.1_2 @4.0_0 @1.5.1_0 @0.1.4_0 @0.28_0 @0.12_0 @3.2.5_0 @5.0_1 @1.2.0_0
Now it is up to the user to decide what's needed and what is not. We've noticed pkgconfig is needed to build many ports,
https://guide.macports.org/#installing.macports.git
Page 17 of 81
MacPorts Guide
22/09/17 8:30 p.m.
and while it is strictly not needed after installation, we'd like to keep it around to avoid installing it over and over again. are only needed to update mplayer2, and since that software is rarely updated, we will python32, texi2html, and yasm re-install those ports again when they are needed. Since they are all distributable, MacPorts will use pre-built binaries for their installation anyway, so re-installing them wouldn't take long anyway. We don't really know why the rest of the leaves were installed, so we're just going to remove them for now. Since we decided to keep pkgconfig, we are going to mark it as manually installed (“requested” in MacPorts lingo) using:
$ sudo port setrequested pkgconfig When you've step-by-step figured out which ports you want to keep on your system and have set them as requested, you'll have a list of unnecessary ports, which you can get rid of using
$ sudo port uninstall leaves Note that uninstalling leaves may mark new ports as leaves, so you will have to repeat the process. You can install the port_cutleaves port, which is a special script for the job. It allows you to interactively decide whether to keep or uninstall a port. Run it as
$ sudo port_cutleaves [Leaf 1 of 8] hs-download-curl @0.1.4_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: ** hs-download-curl @0.1.4_0 will be kept. [Leaf 2 of 8] gmake @4.0_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** gmake @4.0_0 will be uninstalled. [Leaf 3 of 8] texi2html @5.0_1 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** texi2html @5.0_1 will be uninstalled. [Leaf 4 of 8] yasm @1.2.0_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** yasm @1.2.0_0 will be uninstalled. [Leaf 5 of 8] python32 @3.2.5_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** python32 @3.2.5_0 will be uninstalled. [Leaf 6 of 8] py27-docutils @0.12_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** py27-docutils @0.12_0 will be uninstalled. [Leaf 7 of 8] git-flow @0.4.1_2 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** git-flow @0.4.1_2 will be uninstalled. [Leaf 8 of 8] gpgme @1.5.1_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** gpgme @1.5.1_0 will be uninstalled. ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> ---> --->
Deactivating gmake @4.0_0 Cleaning gmake Uninstalling gmake @4.0_0 Cleaning gmake Deactivating texi2html @5.0_1 Cleaning texi2html Uninstalling texi2html @5.0_1 Cleaning texi2html Deactivating yasm @1.2.0_0 Cleaning yasm Uninstalling yasm @1.2.0_0 Cleaning yasm Deactivating python32 @3.2.5_0 Cleaning python32 Uninstalling python32 @3.2.5_0 Cleaning python32 Deactivating py27-docutils @0.12_0 Cleaning py27-docutils Uninstalling py27-docutils @0.12_0 Cleaning py27-docutils Deactivating git-flow @0.4.1_2 Cleaning git-flow Uninstalling git-flow @0.4.1_2 Cleaning git-flow Deactivating gpgme @1.5.1_0 Cleaning gpgme Uninstalling gpgme @1.5.1_0 Cleaning gpgme
https://guide.macports.org/#installing.macports.git
Page 18 of 81
MacPorts Guide
22/09/17 8:30 p.m.
The following ports were uninstalled: gmake @4.0_0 texi2html @5.0_1 yasm @1.2.0_0 python32 @3.2.5_0 py27-docutils @0.12_0 git-flow @0.4.1_2 gpgme @1.5.1_0 Search for new leaves? [no] / (y)es: y [Leaf 1 of 1] py27-roman @2.0.0_0 (active): [keep] / (u)ninstall / (f)lush / (a)bort: u ** py27-roman @2.0.0_0 will be uninstalled. ---> ---> ---> --->
Deactivating py27-roman @2.0.0_0 Cleaning py27-roman Uninstalling py27-roman @2.0.0_0 Cleaning py27-roman
The following ports were uninstalled: py27-roman @2.0.0_0 Search for new leaves? [no] / (y)es: y There are no new leaves to process. You can get a list of all ports you previously set as requested (or installed manually) using:
$ port installed requested We recommend you check the list of leaves from time to time to keep your system free of too much “garbage”. You should also periodically check the list of your requested ports and mark any ports you no longer need as unrequested using
$ sudo port unsetrequested Then check for new leaves to cut down the number of installed ports and the size of your MacPorts installation.
3.4. Port Binaries MacPorts can pre-compile ports into binaries so applications need not be compiled when installing on a target system. MacPorts supports two types of binaries: archives and packages.
3.4.1. Binary Archives Binary archives can only be used on a target system running MacPorts. They allow MacPorts utilities to skip the build (which is usually the phase that takes longest) and begin installation after the destroot phase. Binary archives are automatically created whenever a port is installed, and can also be downloaded from a server. MacPorts runs a buildbot infrastructure that creates prebuilt binary packages for all ports in MacPorts for the default installation prefix. Buildbots exist for systems later or equal to Snow Leopard. If a port builds successfully and its license and those of its dependencies allow binary redistribution, they archives are uploaded to packages.macports.org and will be automatically used by MacPorts during installation. You can manually create an archive (and see debug output for its creation) using
$ sudo port -d archive logrotate ---> Installing logrotate @3.8.6_2+gzip […] DEBUG: Creating logrotate-3.8.6_2+gzip.darwin_13.x86_64.tbz2 […] a . a ./+COMMENT a ./+CONTENTS a ./+DESC a ./+PORTFILE a ./+STATE a ./opt a ./opt/local a ./opt/local/etc a ./opt/local/sbin a ./opt/local/share a ./opt/local/var a ./opt/local/var/run a ./opt/local/var/run/logrotate a ./opt/local/var/run/logrotate/.turd_logrotate a ./opt/local/share/logrotate a ./opt/local/share/man a ./opt/local/share/man/man5 a ./opt/local/share/man/man8
https://guide.macports.org/#installing.macports.git
Page 19 of 81
MacPorts Guide
22/09/17 8:30 p.m.
a ./opt/local/share/man/man8/logrotate.8.gz a ./opt/local/share/man/man5/logrotate.conf.5.gz a ./opt/local/share/logrotate/CHANGES a ./opt/local/share/logrotate/COPYING a ./opt/local/share/logrotate/logrotate.conf.example a ./opt/local/share/logrotate/org.macports.logrotate.plist.example a ./opt/local/sbin/logrotate a ./opt/local/etc/logrotate.d a ./opt/local/etc/logrotate.d/.turd_logrotate DEBUG: Archive logrotate-3.8.6_2+gzip.darwin_13.x86_64.tbz2 packaged Binary archive files are placed in ${prefix}/var/macports/software/. The archive file type is set in macports.conf using the portarchivetype key. The default format is tbz2; other options are: tar, tbz, tbz2, tgz, tlz, txz, xar, zip, cpgz, and cpio.
3.4.2. Binary Packages Binary packages are standalone binary installers that are precompiled; they do not require MacPorts on the target system. As such, they are helpful in generating disk images or installers to be redistributed to users without relying on MacPorts for installation. Binary installers created with MacPorts are usually .pkg (OS X Installer Packages). MacPorts can also convert a .pkg package into an OS X .dmg disk image. You can create binary packages using port as shown in the following examples.
Warning If you want to create installer packages using MacPorts for redistribution, make sure you do not use a standard installation of MacPorts in /opt/local. If you do that, your installer package conflicts with MacPorts on systems that do have MacPorts installed. Instead, follow Section 2.2.4, “Install Multiple MacPorts Copies” and choose a prefix specific to the software you are trying to package, e.g., /opt/logrotate for logrotate. Then use this custom MacPorts installation to build your package.
Create an OS X .pkg installer for the pstree port:
$ sudo port pkg pstree You may also create an OS X .dmg disk image file instead:
$ sudo port dmg pstree In most cases you probably want to package a port and all its library and runtime dependencies in a single package. You can use a metapackage to do this. Create one using:
$ sudo port mpkg gimp2 Just as with a single package, a metapackage can also be wrapped in a .dmg.
$ sudo port mdmg gimp2 All packages are placed in a port's work directory, which you can locate using:
$ port work
Chapter 4. Portfile Development A port is a distribution of software that can be compiled and installed using MacPorts. A Portfile describes all the required steps such as where to get the source code from upstream, which patches have to be applied and which other tools and commands are required to build the source code. Each port consists of multiple files in a directory, usually within a category subdirectory of the root of a ports tree. The MacPorts Project distributes the main ports tree that is by default configured in all installations of MacPorts. This section serves as a reference for the directory structure of a single port and the layout of the files within. The only required file in a port is the Portfile.
4.1. Portfile Introduction A MacPorts Portfile is a Tcl script that usually contains only the simple keyword/value combinations and Tcl extensions as described in the Portfile Reference chapter, though it may also contain arbitrary Tcl code. Every port has a corresponding Portfile, but Portfiles do not completely define a port's installation behavior since MacPorts base has default port installation characteristics coded within it. Therefore Portfiles need only specify required options, though some ports may require nondefault options. A common way for Portfiles to augment or override MacPorts base default installation phase characteristics is by using Portfile phase declaration(s). If you use Portfile phase declaration(s), you should know how to identify the “global” section of a Portfile. Any statements not contained within a phase declaration, no matter where they are located in a Portfile, are said https://guide.macports.org/#installing.macports.git
Page 20 of 81
MacPorts Guide
22/09/17 8:30 p.m.
to be in the global section of the Portfile; therefore the global section need not be contiguous. Likewise, to remove statements from the global section they must be placed within a phase declaration. The main phases you need to be aware of when making a Portfile are these: Fetch Extract Patch Configure Build Destroot The default installation phase behavior performed by the MacPorts base works fine for applications that use the standard configure , make, and make install steps, which conform to phases configure, build, and destroot respectively. For applications that do not conform to this standard behavior, any installation phase may be augmented using pre- and/or postphases, or even overridden or eliminated. See Example Portfiles below.
Note For a detailed description of all port phases, see the Portfile Reference chapter.
4.2. Creating a Portfile Here we list the individual Portfile components for an application that conforms to the standard configure , make, and make install steps of most open source application installs. 1. Modeline This should be the first line of a Portfile. It sets the correct editing options for vim and emacs. See Port Style for more information. Its use is optional and up to the port maintainer.
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-of 2. PortSystem line This statement is required for all ports.
PortSystem
1.0
3. Port name
name
rrdtool
4. Port version
version
1.2.23
5. Port categories A port may belong to more than one category, but the first (primary) category should match the directory name in the ports tree where the Portfile is to reside.
categories
net
6. Platform statement
platforms
darwin
7. Port maintainers A port's maintainers are the people who have agreed to take responsibility for keeping the port up-to-date. The maintainers keyword lists the maintainers' GitHub usernames or email addresses, preferably in the obfuscated form which hides them from spambots. For more, see the full explanation of the maintainers keyword in the Global Keywords section of the Portfile Reference chapter.
maintainers
@neverpanic \ jdoe \ example.org:julesverne
8. Port description
description
Round Robin Database
9. Port long_description
long_description
RRDtool is a system to store and display time-series \ data
10. A port's application homepage
homepage
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
11. A port's download URLs
master_sites https://guide.macports.org/#installing.macports.git
http://oss.oetiker.ch/ rrdtool/pub/ \ Page 21 of 81
MacPorts Guide
22/09/17 8:30 p.m.
ftp://ftp.pucpr.br/rrdtool/
12. Port checksums The checksums specified in a Portfile are checked with the fetched tarball for security. For the best security, use rmd160 and sha256 checksum types.
checksums
rmd160 sha256
7bbfce4fecc2a8e1ca0811 69e70c1a298ab1b75a \ 2829fcb7393bac85925090 b286b1f9c3cd3fbbf8e7f3 579
To find the correct checksums for a port's distribution file, follow one of these examples:
%% openssl dgst -rmd160 rrdtool-1.2.23.tar.gz %% openssl dgst -sha256 rrdtool-1.2.23.tar.gz RIPEMD160( ... rrdtool-1.2.23.tar.gz)= 7bbfce4fecc2a8e1ca081169e70c1a298ab1b75a SHA256( ... rrdtool-1.2.23.tar.gz)= 2829fcb7393bac85925090b286b1f9c3cd3fbbf8e7f or update the version in the Portfile:
%% sudo port edit rrdtool and run:
%% port -v checksum rrdtool ---> Fetching distfiles for rrdtool ---> Verifying checksums for rrdtool ---> Checksumming rrdtool-1.2.23.tar.g z Error: Checksum (rmd160) mismatch for rrdtool-1.2.23.tar.gz Portfile checksum: rrdtool-1.2.23.tar.gz rmd160 ...WRONGCHECKSUM... Distfile checksum: rrdtool-1.2.23.tar.gz rmd160 7bbfce4fecc2a8e1ca081169e70c1a2 Error: Checksum (sha256) mismatch for rrdtool-1.2.23.tar.gz Portfile checksum: rrdtool-1.2.23.tar.gz sha256 ...WRONGCHECKSUM... Distfile checksum: rrdtool-1.2.23.tar.gz sha256 2829fcb7393bac85925090b286b1f9c The correct checksum line may be: checksums rmd160 7bbfce4fecc2a8e1ca0811 69e70c1a298ab1b75a \ sha256 2829fcb7393bac85925090 b286b1f9c3cd3fbbf8e7f3 5796ef4 Error: Failed to checksum rrdtool: Unable to verify file checksums Error: See ...SOMEPATH.../rrdtool/main.log for details. Error: Follow http://guide.macports.org/#project.tickets to report a bug. Error: Processing of port rrdtool failed 13. Port dependencies A port's dependencies are ports that must be installed before another port is installed.
depends_lib
port:perl5.8 \ port:tcl \ port:zlib
14. Port configure arguments (optional)
configure.args
--enable-perl-site-ins tall \ --mandir=${prefix}/share/man
4.3. Example Portfiles In this section we begin by taking a look at a complete simple Portfile; then we see how to augment default phases by defining pre- and post- phases, how to override default phases, and finally how to eliminate port phases.
4.3.1. A Basic Portfile # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: PortSystem
1.0
name version categories platforms license maintainers description long_description homepage master_sites
rrdtool 1.2.23 net darwin GPL-2+ julesverne Round Robin Database RRDtool is a system to store and display time-series data http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ http://oss.oetiker.ch/ rrdtool/pub/ \ ftp://ftp.pucpr.br/rrdtool/
checksums
rmd160 sha256
depends_lib
path:bin/perl:perl5 \
https://guide.macports.org/#installing.macports.git
7bbfce4fecc2a8e1ca081 169e70c1a298ab1b75a \ 2829fcb7393bac8592509 0b286b1f9c3cd3fbbf8e7f3 5796ef413132
Page 22 of 81
MacPorts Guide
22/09/17 8:30 p.m.
port:tcl \ port:zlib
configure.args
--enable-perl-site-ins tall \ --mandir=${prefix}/share/man
4.3.2. Augment Phases Using pre- / postTo augment a port's installation phase, and not override it, you may use pre- and post- installation phases as shown in this example.
post-destroot { # Install example files not installed by the Makefile file mkdir ${destroot}${prefix}/sh are/doc/${name}/exampl es file copy ${worksrcpath}/examp les/ \ ${destroot}${prefix}/share/doc/${name}/examples }
4.3.3. Overriding Phases To override the automatic MacPorts installation phase processing, define your own installation phases as shown in this example.
destroot { xinstall -m 755 -d ${destroot}${prefix}/s hare/doc/${name} xinstall -m 755 ${worksrcpath}/README ${destroot}${prefix}/s hare/doc/${name} }
4.3.4. Eliminating Phases To eliminate a default phase, simply define a phase with no contents as shown.
build {}
Note Because many software packages do not use configure, a keyword is provided to eliminate the configure phase. Another exception is the destroot phase may not be eliminated. See the chapter Portfile Reference for full information.
4.3.5. Creating a StartupItem Startupitems may be placed in the global section of a Portfile.
startupitem.create startupitem.name startupitem.executable
yes nmicmpd "${prefix}/bin/nmicmpd"
4.4. Port Variants Variants are a way for port authors to provide options that may be invoked at install time. They are declared in the global section of a Portfile using the “variant” keyword, and should include carefully chosen variant descriptions.
4.4.1. Example Variants The most common actions for user-selected variants is to add or remove dependencies, configure arguments, and build arguments according to various options a port author wishes to provide. Here is an example of several variants that modify depends_lib and configure arguments for a port.
variant fastcgi description {Add fastcgi binary} { configure.args-append \ --enable-fastcgi \ --enable-force-cgi-red irect \ --enable-memory-limit } variant gmp description {Add GNU MP functions} { depends_lib-append port:gmp configure.args-append --with-gmp=${prefix } } variant sqlite description {Build sqlite support} { depends_lib-append \ port:sqlite3 configure.args-delete \ https://guide.macports.org/#installing.macports.git
Page 23 of 81
MacPorts Guide
22/09/17 8:30 p.m.
}
--without-sqlite \ --without-pdo-sqlite configure.args-append \ --with-sqlite \ --with-pdo-sqlite=${pr efix} \ --enable-sqlite-utf8
Note Variant names may contain only the characters A-Z, a-z, and the underscore character “_”. Therefore, take care to never use hyphens in variant names.
In the example variant declaration below, the configure argument --without-x is removed and a number of others are appended.
variant x11 description {Builds port as an X11 program with Lucid widgets} { configure.args-delete --without-x configure.args-append --with-x-toolkit=luci d \ --without-carbon \ --with-xpm \ --with-jpeg \ --with-tiff \ --with-gif \ --with-png depends_lib-append lib:libX11:XFree86 \ lib:libXpm:XFree86 \ port:jpeg \ port:tiff \ port:libungif \ port:libpng }
4.4.2. Variant Actions in a Phase If a variant requires options in addition to those provided by keywords using -append and/or -delete, in other words, any actions that would normally take place within a port installation phase, do not try to do this within the variant declaration. Rather, modify the behavior of any affected phases when the variant is invoked using the variant_isset keyword.
post-destroot { xinstall -m 755 -d ${destroot}${prefix}/e tc/ xinstall ${worksrcpath}/exampl es/foo.conf \ ${destroot}${prefix}/etc/ if {[variant_isset carbon]} { delete ${destroot}${prefix}/bi n/emacs delete ${destroot}${prefix}/bi n/emacs-${version} } }
4.4.3. Default Variants Variants are used to specify actions that lie outside the core functions of an application or port, but there may be some cases where you wish to specify these non-core functions by default. For this purpose you may use the keyword default_variants.
default_variants
+foo +bar
Note The default_variant keyword may only be used in the global Portfile section.
4.5. Patch Files Patch files are files created with the Unix command diff that are applied using the command patch to modify text files to fix bugs or extend functionality.
4.5.1. Creating Portfile Patches If you wish to contribute modifications or fixes to a Portfile, you should do so in the form of a patch. Follow the steps below to create Portfile patch files 1. Make a copy of the Portfile you wish to modif y; both files must be in the same director y, though it may be any directory.
https://guide.macports.org/#installing.macports.git
Page 24 of 81
MacPorts Guide
22/09/17 8:30 p.m.
%% cp -p Portfile Portfile.orig 2. Edit the file to make it as you want it to be after it is fetched. 3. Now use the Unix command diff -u to create a “unified” diff patch file. Put the name of the port in the patchfile, for example, Portfile-rrdtool.diff.
%% diff -u Portfile.orig Portfile > Portfile-rrdtool.diff 4. A patch file that is a “unified” diff file is the easiest to interpre t by humans and this type should always be used for ports. The Portfile patch below will change the version and checksums when applied.
--- Portfile.orig 2011-07-25 18:52:12.000000000 -0700 +++ Portfile 2011-07-25 18:53:35.000000000 -0700 @@ -2,7 +2,7 @@ PortSystem 1.0 name foo -version +version categories maintainers description @@ -13,9 +13,9 @@ homepage master_sites -checksums +checksums extract.suffix platforms
1.3.0 1.4.0 net nomaintainer A network monitoring daemon. http://rsug.itd.umich.edu/software/${name} ${homepage}/files/ rmd160 f0953b21cdb5eb327e40d4 b215110b71 rmd160 01532e67a596bfff6a54aa 36face26ae .tgz darwin
Now you may attach the patch file to a MacPorts Trac ticket for the port author to evaluate.
4.5.2. Creating Source Code Patches Necessary or useful patches to application source code should generally be sent to the application developer rather than the port author so the modifications may be included in the next version of the application. Generally speaking, you should create one patch file for each logical change that needs to be applied. Patchfile filenames .diff, where the identifier should uniquely distinguish the file and generally be of the form patch- is a hint of what the patch does. For example, this can be the filename of the patched file as in patch- srcMakefile.in.diff. You may use patch files that patch multiple files under these conditions: You find existing patch files that do so. If fixing a particular problem or bug requires changes in multiple files—in those cases the patch filename should .diff reference the problem or bug, for example: patch- destdir-variable-fix To create a patch to modify a single file, follow the steps below. 1. Locate the file you wish to patch in its original location within the unpacked source director y and make a duplicate of it.
%% cd ~/Downloads/foo-1.34/src %% cp -p Makefile.in Makefile.in.orig 2. Edit the file and modify the text to reflect your corrections. 3. Now cd to the top-level directory of the unpacked source, and use the Unix command diff -u to create a “unified” diff patch file.
%% cd ~/Downloads/foo-1.34 %% diff -u src/Makefile.in.orig src/Makefile.in > patch-src-Makefile.in.diff You should execute diff from the top-level directory of the unpacked source code, because during the patch phase MacPorts by default uses the patch argument -p0, which does not strip prefixes with any leading slashes from file names found in the patch file (as opposed to -p1 that strips one, etc), and any path not relative to the top-level directory of the unpacked source will fail during the patch phase.
Note If you find an existing source file patch you wish to use that contains leading path information (diff was executed from a directory higher than the top-level source directory), you will need to use the patch phase keyword patch.pre_args to specify a -px value for how many prefixes with leading slashes are to be stripped off.
4. A patch file that is a “unified” diff file is the easiest to interpre t by humans and this type should always be used for ports. See the example below where a patch adds DESTDIR support to Makefile.in.
https://guide.macports.org/#installing.macports.git
Page 25 of 81
MacPorts Guide
22/09/17 8:30 p.m.
--- src/Makefile.in.orig 2007-06-01 16:30:47.000000000 -0700 +++ src/Makefile.in 2007-06-20 10:10:59.000000000 -0700 @@ -131,23 +131,23 @@ $(INSTALL_DATA)/gdata $(INSTALL_DATA)/perl install-lib: -mkdir -p $(INSTALL_LIB) -mkdir -p $(DESTDIR)$(INSTALL_L IB) $(PERL) tools/install_lib -s src -l $(INSTALL_LIB) $(LIBS) cp $(TEXT) $(INSTALL_LIB)/ + cp $(TEXT) $(DESTDIR)$(INSTALL_ LIB)/ +
5. Place the patch patch-src-Makefile.in.diff in the directory ${portpath}/files and use it in a port using the patchfiles keyword. ${portpath} may be in a local Portfile repository during development, or files/ may be in a port's ${portpath} in the global MacPorts repository.
patchfiles
patch-src-Makefile.in.diff
4.5.3. Manually Applying Patches MacPorts applies patch files automatically, but you may want to know how to apply patch files manually if you want to test patch files you have created or you wish to apply uncommitted Portfile patches. 1. Change to the directory containing the file to be patched. In this example, we'll apply a Portfile patch to the postfix port.
%% cd $(port dir postfix) 2. Now apply the patch from your Downloads folder, or wherever you put it. The patchfile knows the name of the file to be patched.
%% patch -p0 < ~/Downloads/Portfile-postfix.diff patching file Portfile
4.6. Local Portfile Repositories To create and test Portfiles that are not yet published in the MacPorts ports tree, you may create a local Portfile repository as shown. Replace the hypothetical user julesverne with your username in the example below. 1. Open sources.conf in a text editor. For example, to open it into TextEdit:
%% open -e ${prefix}/etc/macports/sources.conf 2. Insert a URL pointing to your local repository locatio n before the rsync URL as shown.
file:///Users/julesverne/ports rsync://rsync.macports.org/release/ports [default]
Note The file URL should always appear before the rsync URL so that local Portfiles can be tested that are duplicated in the MacPorts tree, because port will always operate on the first Portfile it encounters.
3. Place the Portfiles you create inside a directory whose name matches the port, which should in turn be placed inside a directory that reflects the port's primary category (the first category entry in the Portfile). For example, to create the directory for a hypothetical port “bestevergame” and to begin editing its Portfile in TextEdit, you can use these commands:
%% mkdir -p ~/ports/game s/bestevergame %% cd ~/ports/games/bestevergame %% touch Portfile %% open -e Portfile See other sections in the Guide for help writing Portfiles. If you've already written the Portfile elsewhere, you can instead copy the Portfile into this directory. 4. If your Portfile needs to apply any patches to the port's source files, create a files directory and place the patchfiles in it, and reference the patchfiles in your Portfile, as explained in Creating Source Code Patches. 5. After you create or update your Portfile, use portindex in the local repository's directory to create or update the index of the ports in your local repository.
%% cd ~/ports %% portindex Creating software index in /Users/julesverne/ports Adding port games/bestevergame Total number of ports parsed: https://guide.macports.org/#installing.macports.git
1 Page 26 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Ports successfully parsed: Ports failed:
1 0
Once the local port is added to the PortIndex, it becomes available for searching or installation as with any other Portfile in the MacPorts tree:
%% port search bestever bestevergame @1.1 (games) The Best Ever Game
4.7. Portfile Best Practices This section contains practical guidelines for creating Portfiles that install smoothly and provide consistency between ports. The following sections are on the TODO list.
4.7.1. Port Style Portfiles may be thought of as a set of declarations rather than a piece of code. It is best to format the port file is if it were a table consisting of keys and values. In fact, the simplest of ports will only contain a small block of values. Nicely formatted compact tables will result in more values being visible at the same time. The two columns should be separated by spaces (not tabs), so you should set your editor to use soft tabs, which are tabs emulated by spaces. By default, the top line of all Portfiles should use a modeline that defines soft tabs for the vim and emacs editors as shown.
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: The left column should consist of single words, and will be separated from the more complex right side by spaces in multiples of four. Variable assignments and variant declarations are exceptions, and may be considered a single word on the left side, with a single space between words.
set libver "8.5" When items require multiple lines with line continuation, they can be separated from the previous and next items with a blank line. Indent the additional lines to the same column that the right side begins on in the first line.
checksums
rmd160 sha256
7bbfce4fecc2a8e1ca081 169e70c1a298ab1b75a \ 2829fcb7393bac8592509 0b286b1f9c3cd3fbbf8e7f3 5796ef41
Should a key item such as a phase or variant require braces, the opening brace should appear on the same line and the closing brace should be on its own line. The block formed by the braces is indented for visual clearance. Braces merely quoting strings, for example the description of variants, are placed on the same line without line breaks.
variant mysql5 description {Enable support for MySQL 5} { depends_lib-append port:mysql5 configure.args-replace --without-mysql5 --with-mysql5 } Frequently multiple items are necessary in the second column. For example, to set multiple source download locations, multiple master_sites must be defined. Unless the second column items are few and short you should place each additional item on a new line and separate lines with a backslash. Indent the lines after the first line to make it clear the items are second column values and also to emphasize the unity of the block.
destroot.keepdirs
${destroot}${prefix}/ var/run \ ${destroot}${prefix}/ var/log \ ${destroot}${prefix}/var/cache/mrtg
4.7.2. Don't Overwrite Config Files TODO:
4.7.3. Install Docs and Examples TODO:
4.7.4. Provide User Messages TODO:
4.7.5. Use Variables TODO: Set variables so changing paths may be done in one place; use them anytime it makes updates simpler: distname ${name}-src-${version}
4.7.6. Renaming or replacing a port If there is the need to replace a port with another port or a renaming is necessary for some reason, the port should be marked as replaced_by. As an illustration of a typical workflow the port “skrooge-devel” shall be taken. This port had been used for testing new versions of skrooge, but it turned out to have become unnecessary due to the fact that skrooge's developers currently prefer https://guide.macports.org/#installing.macports.git
Page 27 of 81
MacPorts Guide
22/09/17 8:30 p.m.
a distribution via port “skrooge” instead. At the end of this section the use of the obsolete PortGroup is suggested as an even shorter approach to the below described workflow. 4.7.6.1. The long way
Skrooge's original devel port file looked like this:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: PortSystem PortGroup
1.0 kde4
fetch.type svn.url svn.revision
svn svn://anonsvn.kde.org/home/kde/trunk/extragear/office/skrooge 1215845
name version
skrooge-devel 0.8.0-${svn.revision}
categories maintainers description long_description
kde finance mk pixilla openmaintainer Skrooge Personal finance management tool for KDE4, with the aim of being providing powerful functions such as reporting (including graphi Undo/Redo, encryption, and much more...
conflicts
skrooge
platforms license
darwin GPL-3
homepage master_sites
http://skrooge.org http://skrooge.org/files/
livecheck.type
none
distname
skrooge
depends_lib-append
port:kdelibs4 \ port:libofx \ port:qca-ossl \ port:kdebase4-runtime \ port:oxygen-icons
1.1
The following steps have to be taken to ensure a smooth transition for a MacPorts user updating his local installation using sudo port upgrade : 1. add the line replaced_by foo where foo is the port this one is replaced by; when a user upgrades this port, MacPorts will instead install the replacement port
replaced_by
skrooge
2. increase the version, revision, or epoch, so that users who have this port installed will get notice in port outdated that they should upgrade it and trigger the above process
revision
1
3. clear distfiles (have a line reading only distfiles) so that no distfile is downloaded for this stub port
distfiles 4. delete master_sites since there aren't any distfiles to download 5. disable livecheck
livecheck.type
none
6. add a pre-configure block with a ui_error and return -code error explaining to users who try to install this port that the port has been replaced
pre-configure { ui_error "Please do not install this port since it has been replaced by 'sk return -code error } With above modifications the port file eventually looks like this:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: PortSystem
1.0
name svn.revision
skrooge-devel 1215845
https://guide.macports.org/#installing.macports.git
Page 28 of 81
MacPorts Guide
22/09/17 8:30 p.m.
version revision
0.8.0-${svn.revision} 1
replaced_by
skrooge
categories maintainers description long_description
kde finance mk pixilla openmaintainer Skrooge Personal finance management tool for KDE4, with the aim of being providing powerful functions such as reporting (including graphi Undo/Redo, encryption, and much more...
platforms license
darwin GPL-3
homepage
http://skrooge.org
livecheck.type
none
pre-configure { ui_error "Please do not install this port since it has been replaced by 'skrooge return -code error } distfiles A user upgrading ports will experience the following for port “skrooge-devel”:
%% sudo port upgrade skrooge-devel ---> skrooge-devel is replaced by skrooge ---> Computing dependencies for skrooge ---> Fetching skrooge ---> Verifying checksum(s) for skrooge ---> Extracting skrooge ---> Configuring skrooge ---> Building skrooge ---> Staging skrooge into destroot ---> Deactivating skrooge-devel @0.8.0-1215845_0 ---> Cleaning skrooge-devel ---> Computing dependencies for skrooge ---> Installing skrooge @0.8.0.6_0 ---> Activating skrooge @0.8.0.6_0 ########################################################## # Don't forget that dbus needs to be started as the local # user (not with sudo) before any KDE programs will launch # To start it run the following command: # launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist ########################################################## ###################################################### # Programs will not start until you run the command # 'sudo chown -R $USER ~/Library/Preferences /KDE' # replacing $USER with your username. ###################################################### ---> Cleaning skrooge In case a user actually tries to install the obsolete port “skrooge-devel” it would be pointed out by an error message that this is impossible now:
%% sudo port install skrooge-devel ---> Fetching skrooge-devel ---> Verifying checksum(s) for skrooge-devel ---> Extracting skrooge-devel ---> Configuring skrooge-devel Error: Please do not install this port since it has been replaced by 'skrooge'. Error: Target org.macports.configure returned: Log for skrooge-devel is at: /opt/local/var/macports/logs/_opt_local_var_macports_so Error: Status 1 encountered during processing. To report a bug, see 4.7.6.2. The shortcut: PortGroup obsolete
Using the PortGroup obsolete makes the task described in the previous subsection much easier:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: PortSystem replaced_by PortGroup name https://guide.macports.org/#installing.macports.git
1.0 skrooge obsolete 1.0 skrooge-devel Page 29 of 81
MacPorts Guide
22/09/17 8:30 p.m.
svn.revision version revision
1215845 0.8.0-${svn.revision} 2
The PortGroup defines a number of reasonable defaults for a port that is only there to inform users that they should uninstall it and install something else instead. You might want to override some of the defaults though. For details have a look at the PortGroup's source code in ${prefix}/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/obsolete1.0.tcl.
Note It is important to specify replaced_by BEFORE the PortGroup line!
4.7.7. Removing a port If a port has to be removed from MacPorts one should consider the hints concerning replacing it by some alternative port given above. It is recommended to wait one year before the port directory is actually removed from the MacPorts ports tree. If there is no replacement for a port, it can simply be deleted immediately.
4.8. MacPorts' buildbot The buildbot is a port build-service currently supporting building of all committed ports for Snow Leopard, Lion, and Mountain Lion using the MacPorts AutoBuild ( MPAB) scripts. Every time a maintainer commits changes to MacPorts' ports Git repository the buildbot will check whether a rebuild of the corresponding port(s) would be necessary. If the port(s) in question are distributable their binary archives will be kept for subsequent distribution for all versions of the Mac operating system for which build machines are available. See the list of builders to find out which platforms these currently are. If a build error occurred for a port its maintainer will be informed via an email so that problems which did not surface on the maintainer's machine will not go unnoticed. Port maintainers will find the waterfall and the builders views most useful since they give information about the build status and offer the possibility to build ones port(s) on specific builders. Thus the buildbot helps to keep MacPorts consistent on various OS X versions, i.e., a maintainer does not need access to these versions anymore in order to assure that the port(s) maintained build without problems. Currently only the default port variants will be built and kept.
Chapter 5. Portfile Reference This chapter serves as a reference for the major elements of a Portfile: port phases, dependencies, StartupItems, variables, keywords, and Tcl extensions.
5.1. Global Keywords MacPorts keywords are used to specify required or optional items within a Portfile, or to override default options used by MacPorts base for individual ports. Keywords are to be used within the “global” and “variant” sections of Portfiles, and not within optional port phase declarations. The global keywords listed below specify information for ports as a whole, whereas the keywords listed under a port phase specify information to be used during a particular installation phase. PortSystem
The first non-comment line of every Portfile; it should be followed by PortGroup inclusions (if any) and then a blank line. It defines which version of the Portfile interpreter will be used. (There is currently only one version.)
PortSystem
1.0
name
The name of the port. To avoid special interpretation by shells and the like, names should contain only alphanumeric characters, underscores, dashes or dots. For projects whose proper names contain “+” characters, change these to “x” (e.g., “libstdc++” becomes “libstdcxx”).
name
foo
version
The version of the ported software.
version
1.23.45
revision
Optional keyword (default is 0) that is used to track port revisions. It should not be incremented for port revisions
https://guide.macports.org/#installing.macports.git
Page 30 of 81
MacPorts Guide
22/09/17 8:30 p.m.
unless it would benefit users to upgrade an installed port, and cleared when the port is updated to a newer version. It should be used if a bug in the Portfile was found and all installations of this port have to be updated. If the change only affects new installations, there is no need to increase it.
revision
1
epoch
An optional keyword (default value is 0) that must be used when a port is updated to a version that is numerically less than the previous version, for example 1.10 -> 1.2 or 20070928 -> 1.0. Some Portfile authors have used large epoch values that look like a date, but there is no reason to do so. The epoch is simply an unsigned integer, and the only requirement is that it never be decreased.
epoch
1
Note An epoch is not needed for most ports. If a port's version numbers advance in normal dotteddecimal sequence, there is no reason to add an epoch.
categories
The category under which the ported software falls. The first category should be the same as the directory within which the Portfile is stored; secondary and tertiary categories may be selected.
categories
net security
maintainers
A port's maintainers are the people who have agreed to take responsibility for keeping the port up-to-date. Most ports have only a single maintainer, but some ports have two or more co-maintainers. The maintainers keyword lists the maintainers' GitHub usernames or email addresses. GitHub usernames start with an @ symbol. Email addresses are preferably listed in the obfuscated form below to hide them from spambots: For addresses in domain @macports.org, simply omit the domain name. For addresses in other domains, e.g., , use the convention example.org:account to specify the address. In the example below, the port is maintained by a GitHub user named neverpanic, and the owners of the two email addresses and
maintainers
@neverpanic \ jdoe \ example.org:julesverne
Braces can be used to express that these refer to the same person, for example the GitHub username and an email. In the following example, the port is maintained by a GitHub user named jverne, that can also be contacted directly at .
maintainers
{@jverne example.org:julesvern e}
Note The address nomaintainer designates a port that is not maintained by anybody and may be modified by any committer. Feel free to claim maintainership of a nomaintainer port if desired. The address openmaintainer designates a port that has a maintainer who allows minor changes to be committed without his or her prior approval. Port maintainers who are not committers are encouraged to add openmaintainer to their ports.
description
A one-sentence description of the ported software.
description
A classic shooter arcade game.
long_description
A long description of the ported software. Break long lines with escaped newlines.
long_description
A classic shooter arcade game derived from \ the game alien-munchers. Not suitable for \ children under two years old.
homepage
Port application's homepage.
homepage
http://www.example.org/apps
platforms
A list of the platforms on which the port has been tested. Required, but not interpreted in any way by the software at this time; it is purely informational for users. Possible values: darwin (= macosx or puredarwin), macosx,
https://guide.macports.org/#installing.macports.git
Page 31 of 81
MacPorts Guide
22/09/17 8:30 p.m.
puredarwin, freebsd, linux, sunos, netbsd . In general, it can just be set to darwin. (puredarwin is an OS based on Apple's open-source Darwin releases without any of Apple's proprietary bits.) See also os.platform .
platforms
darwin
supported_archs
The CPU architectures for which this port can be built. Archs currently supported by OS X are: i386, ppc, ppc64, x86_64. If this option is not set, it is assumed that the port can build for all archs. If a port does not install any architecture-specific files, use the special value noarch. If the building architecture isn't among supported_archs, port fails with an error message, except when building on x86_64 and supported_archs contains i386 or when building on ppc64 and supported_archs contains ppc, in which case the port will be built in 32-bit mode.
supported_archs
i386 ppc
supported_archs
noarch
license
The proper format for license consists of the license name, followed by a hyphen and number if indicating a specific version. A space should be placed between licenses if there is more than one that applies. If an element in the license list is itself a list, it is interpreted as offering a choice of any one of the licenses in the sub-list. If the version number is a “.0” version, the “.0” should be omitted to make the version an integer. If the author gives the choice of using a given license or “any later version” of it, append a plus sign (+) to the version number. If the version specified in this case is also the earliest version, just leave out the version number entirely since it implies all versions.
license
GPL-3
license
{freetype GPL}
5.2. Global Variables Global variables are variables available to any Portfile. For a list of additional variables available to ports that are assigned to a MacPorts Portgroup, see portgroup(7). All of these variables except prefix are read-only! prefix
Installation prefix, set at compile time and displayed in ${prefix}/etc/macports/macports.conf —- may be overridden on a per-port basis, for example to install into a wholly-contained subdirectory of ${prefix}, but most ports should have no reason to do so. Default: /opt/local libpath
Path to the MacPorts Tcl libraries. portpath
Full path to the Portfile of the port being executed. Portfile repositories are defined in the file sources.conf . Default: ${prefix}/var/macports/sources/rsync.macports.org/release/ports/ // filesdir
Path to files directory relative to ${portpath}. Value: files filespath
Full path to files directory. Value: ${portpath}/${filesdir} workpath
Full path to work directory. Value: ${portbuildpath}/work worksrcpath
Full path to extracted source code. Value: ${workpath}/${worksrcdir} destroot
Full path into which software will be destrooted. Value: ${workpath}/destroot distpath
Location to store downloaded distfiles. Value: ${sysportpath}/distfiles/${dist_subdir}/ install.user
The Unix user at the time of port installation.
https://guide.macports.org/#installing.macports.git
Page 32 of 81
MacPorts Guide
22/09/17 8:30 p.m.
install.group
The Unix group at the time of port installation. os.platform
The underlying operating system platform (e.g., “darwin” on OS X, “freebsd”, etc.). os.arch
The hardware architecture -- either “ powerpc” or “i386”. os.version
The version number of the host operating system (e.g., “12.3.0” for Darwin 12.3.0 a.k.a. OS X 10.8.3). os.endian
Endianness of the processor -- either “big” (on PowerPC systems) or “little” (on Intel systems). os.major
The major version number of the host operating system (e.g., “12” for Darwin 12.x).
5.3. Port Phases 5.3.1. Introduction The MacPorts port installation process has a number of distinct phases that are described in detail in this section. The default scripts coded into MacPorts base performs the standard configure , make, and make install steps. For applications that do not conform to this standard, installation phases may be declared in a Portfile to augment or override the default behavior as described in the Portfile Development chapter. fetch
Fetch the ${distfiles} from ${master_sites} and place it in ${prefix}/var/macports/distfiles/${name}. checksum
Compare ${checksums} specified in a Portfile to the checksums of the fetched ${distfiles}. extract
Unzip and untar the ${distfiles} into the path ${prefix}/var/macports/build/..../work patch
Apply optional patch files specified in ${patchfiles} to modify a port's source code file(s). configure
Execute ${configure.cmd} in ${worksrcpath}. build
Execute ${build.cmd} in ${worksrcpath}. test
Execute commands to run test suites bundled with a port, available only for a fraction of ports. This is an optional phase, run only if port test is executed, and always works with a build from source, not a binary. A failure is only for the user's information, and does not block a subsequent installation from the build. destroot
Execute the command make install DESTDIR=${destroot}in ${worksrcpath}.
Note Using a DESTDIR variable is a part of standard GNU coding practices, and this variable must be supported in an application's install routines for MacPorts' destroot phase to work without manual Portfile scripting or source patching. Urge developers to fully support DESTDIR in their applications.
Understanding the destroot phase is critical to understanding MacPorts, because, unlike some package management systems, MacPorts “stages” an installation into an intermediate location, not the final file destination. MacPorts uses the destroot phase to provide: Port uninstalls - a port's files may be cleanly uninstalled because all files and directories are recorded during install. Multiple port versions may be installed on the same host, since a port's files are not directly inserted into ${prefix} but rather hard-linked into ${prefix} from an intermediate location during a later activation phase. Any empty directories in ${destroot} upon completion of the destroot phase are removed unless a directory name is placed in the value field of the optional destroot.keepdirs keyword. install
Archive a port's destrooted files into ${prefix}/var/macports/software. See Port Images in the MacPorts
https://guide.macports.org/#installing.macports.git
Page 33 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Internals chapter for details. activate
Extract the port's files from the archive in ${prefix}/var/macports/software to their final installed locations, usually inside ${prefix}.
5.3.2. Installation Phase Keywords MacPorts keywords are used to specify required or optional items within a Portfile, or to override default options used by MacPorts base for individual ports. Keywords are to be used within the “global” and “variant” sections of Portfiles, and not within optional port phase declarations. In other words, port phase keywords are not located within port phase declarations, but rather they refer to port phases and set options for those phases, and they take effect whether or not phase declarations have been explicitly defined in a Portfile. 5.3.2.1. Keyword List Modifiers (-append, -delete, -replace, -strsed)
Keyword list modifiers are keywords that end in -append, -delete or -replace. Keywords that support list modifiers are identified under appropriate reference sections below. -append adds a value to the keyword, -delete removes a previously added item. -replace takes two arguments and replaces the first value from the keyword with the second value. -strsed treats the keyword value as a string and filters it through strsed using the given pattern. There is also a deprecated syntax for -replace which takes only one argument and behaves the same as -strsed. Keyword list modifiers are most frequently used for these three purposes: 1. Preserve configure defaults set by a previously executed Portfile keyword or by MacPorts base MacPorts base sets the gcc compiler flags CFLAGS and LDFLAGS for all ports using configure.cflags and configure.ldflags, therefore to keep from overwriting the default compiler flags use configure.cflagsappend and configure.ldflags-append.
configure.cflags-append configure.ldflags-append 2. Preserve PortGroup Dependencies Ports in a PortGroup have default library dependencies set by MacPorts base. Therefore, never use depends_lib in ports belonging to a PortGroup or it will overwrite the default library dependencies. Instead, use depends_libappend. 3. Add or Delete Items for Variants When a variant requires more or fewer dependencies, distfiles, or patchfiles, when the variant is invoked you want to add or remove items to the appropriate keyword values list set in the global section of the Portfile. Use the appropriate keywords, for example:
depends_lib-append or depends_lib-delete depends_lib-replace distfiles-append or distfiles-delete distfiles-replace patchfiles-append or patchfiles-delete patchfiles-replace 5.3.2.2. Keyword Argument Modifiers (.pre_args / .post_args)
Keywords that support pre_args and post_args are used to assemble command strings together in a row, as described in the reference sections below. But it should be noted that all keyword argument modifiers implicitly support keyword list modifiers. For example, the keyword configure.pre_args also supports configure.pre_args-append and configure.pre_args-delete.
5.3.3. Fetch Phase Keywords The list of keywords related to the fetch phase. master_sites
A list of URLs from which a port's ${distfiles} may be retrieved. Keyword values for master_sites may include predefined site lists known as “mirrors”, such as sourceforge, gnu, etc. The file(s) declared in ${distfiles} will be fetched from one of the locations defined in master_sites, while trying to find the best reachable mirror for the user's connection. For a complete list of mirrors and their list of sites, see the file mirror_sites.tcl located in _resources/port1.0/fetch/ in the ports tree.
Note If a master_sites keyword has multiple values, after any mirrors are expanded the list of sites is sorted by ping response times. The sites are then tried in sorted order until matching ${distfiles} are found.
Default: none (but the macports_distfiles mirror is always implicitly appended) Examples:
https://guide.macports.org/#installing.macports.git
Page 34 of 81
MacPorts Guide
22/09/17 8:30 p.m.
master_sites
http://www.example.org/ files/ \ http://www.examplemirror.org/example_org/files/
You may also use mirror site lists predefined by MacPorts. Here the sourceforge, gnu, and freebsd mirrors are used.
master_sites
sourceforge gnu freebsd
When using mirror master_sites, the subdirectory ${name} is checked on every mirror. If the mirror subdirectory does not match ${name}, then you may specify it using after the mirror separated by a colon.
master_sites
sourceforge:widget \ gnu:widget
For ports that must fetch multiple download files from different locations, you must label the files with tags and match the tags to a distfiles keyword. The format is mirror:subdirectory:tag. In the example below, file_one.tar.gz is fetched from sourceforge mirrors in subdirectory ${name}; file tagtwo.tar.gz is fetched from the gnu mirrors in subdirectory sources.
master_sites
sourceforge::tagone \ gnu:sources:tagtwo
distfiles
file_one.tar.gz:tagone \ file_two.tar.gz:tagtwo
master_sites.mirror_subdir
Subdirectory to append to all mirror sites for any list specified in ${master_sites}. Default: ${name} Example:
master_sites.mirror_subdir
magic
patch_sites
A list of sites from which a port's patchfiles may be downloaded, where applicable. Default: ${master_sites} Example:
patch_sites
ftp://ftp.patchcityrepo.com/pub/magic/patches
patch_sites.mirror_subdir
Subdirectory to append to all mirror sites for any list specified in ${patch_sites}. Default: ${name} Example:
patch_sites.mirror_subdir
magic
distname
The name of the distribution filename, not including the extract suffix (see below). Default: ${name}-${version} Example:
distname
${name}
distfiles
The full distribution filename, including the extract suffix. Used to specify non-default distribution filenames; this keyword must be specified (and tags used) when a port has multiple download files (see master_sites). Default: ${distname}${extract.suffix} Examples:
distfiles
${name}-dev_src.tgz
distfiles
file_one.tar.gz:tagone \ file_two.tar.gz:tagtwo
dist_subdir
Create a sub-directory in distpath to store all fetched files. Default: ${name} Example:
dist_subdir https://guide.macports.org/#installing.macports.git
vim${version} Page 35 of 81
MacPorts Guide
22/09/17 8:30 p.m.
worksrcdir
Sets the path to source directory relative to workpath. It can be used if the extracted source directory has a different name then the distfile. Also used if the source to be built is in a subdirectory. Default: ${distname} Examples:
worksrcdir
${name}-src-${version}
worksrcdir
${distname}/src
5.3.3.1. Advanced Fetch Options
Some mirrors require special options for a resource to be properly fetched. fetch.type
Change the fetch type. This is only necessary if a bzr, cvs, git, hg, or svn checkout is be used. standard is used for a normal http or ftp fetch using ${distfiles} and is used as default. Default: standard Values: standard bzr cvs git hg svn Example:
fetch.type svn.url svn.revision
svn svn://example.org 2100
fetch.user
HTTP or FTP user to fetch the resource. Default: none Example:
TODO: add example fetch.password
HTTP or FTP password to fetch the resource. Default: none Example:
TODO: add example fetch.use_epsv
Whether to use EPSV command for FTP transfers. Default: yes Example:
fetch.use_epsv
no
fetch.ignore_sslcert
Whether to ignore the host SSL certificate (for HTTPS). Default: no Example:
fetch.ignore_sslcert
yes
5.3.3.2. Fetch from BZR
Bzr may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via bzr may cause non-reproducible builds, so it is strongly discouraged. The bzr fetch.type is used to fetch source code from a bzr repository. bzr.url
This specifies the url from which to fetch files. Default: none Examples:
bzr.url
lp:inkscape
bzr.url
lp:~callelejdfors/pycg/trunk
bzr.revision
https://guide.macports.org/#installing.macports.git
Page 36 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Optional tag for fetching with bzr, this specifies the revision to checkout Default: -1 (the last committed revision) Example:
bzr.revision
2209
5.3.3.3. Fetch from CVS
CVS may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via CVS may cause non-reproducible builds, so it is strongly discouraged. The cvs fetch.type is used to fetch source code from a CVS repository. cvs.root
Specify the url from which to fetch files. Default: none Example:
cvs.root
:pserver:[email protected]:/sources/emacs
cvs.password
Password to login to the CVS server. Default: none Example:
cvs.password
nice-password
cvs.tag
Optional for fetching with CVS, this specifies the code revision to checkout. Default: none Example:
cvs.tag
HEAD
cvs.date
A date that identifies the CVS code set to checkout. Default: none Example:
cvs.date
"12-April-2007"
cvs.module
A CVS module from which to check out the code. Default: none Example:
cvs.module
Sources
5.3.3.4. Fetch from Git
Git may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Git may cause non-reproducible builds, so it is strongly discouraged. The git fetch.type is used to fetch source code from a git repository. git.url
This specifies the url from which to fetch files. Default: none Examples:
git.url
git://git.kernel.org/pub/scm/git/git.git
git.url
http://www.kernel.org/pub/scm/git/git.git
git.branch
Optional tag for fetching with git, this specifies the tag or other commit-ish that git should checkout. Note that any tag on a branch besides HEAD should be prefixed by origin/. Default: none Example:
https://guide.macports.org/#installing.macports.git
Page 37 of 81
MacPorts Guide
22/09/17 8:30 p.m.
git.branch
72bf1c8
git.branch
origin/next
5.3.3.5. Fetch from Mercurial
Mercurial may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Mercurial may cause non-reproducible builds, so it is strongly discouraged. The hg fetch.type is used to fetch source code from a Mercurial repository. hg.url
This specifies the url from which to fetch files. Default: none Examples:
hg.url
http://www.kernel.org/hg/index.cgi/linux-2.6/
hg.url
http://hg.intevation.org/mercurial
hg.tag
Optional tag which should be fetched. Can be a Mercurial tag or a revision. To prevent non-reproducible builds use of tip as revision is discouraged. Default: tip Example:
hg.tag
v1.3
hg.tag
ceb884843737
5.3.3.6. Fetch from Subversion
Subversion may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Subversion may cause non-reproducible builds, so it is strongly discouraged. The svn fetch.type is used to fetch source code from an svn repository. svn.url
This specifies the url from which to fetch files. Default: none Examples:
svn.url
http://www.example.com/svn-repo/mydirectory
svn.url
svn://svn.example.com/svn-repo/mydirectory
svn.revision
Optional tag for fetching with Subversion, this specifies the peg revision to checkout; it corresponds to the @REV syntax of the svn cli. Default: none Example:
svn.revision
37192
svn.method
Optional tag for fetching with Subversion, this specifies whether to check out the code into a working copy, or just export it without the working copy metadata. An export is preferable because it takes half the disk space, but some software expects to be built in a working copy (for example because it wants to record the revision number into itself somewhere). Default: export Example:
svn.method
checkout
5.3.4. Checksum Phase Keywords The list of keywords related to the checksum phase. checksums
Checksum(s) of the distribution files. For ports with multiple distribution files, filenames must be included to associate files with their checksums. At least two checksum types (typically rmd160 and sha256) should be used to ensure the integrity of the distfiles.
https://guide.macports.org/#installing.macports.git
Page 38 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: none Examples:
checksums
rmd160 sha256
0c1147242adf476f5e93f4d 59b553ee3ea378b23 \ baf8a29ff721178317aac7b 864c2d392b1accc02de867 7
checksums
${distname}${extract.su ffix} \ rmd160 0c1147242adf476f5e93f4 d59b553ee3ea378b23 \ sha256 883715307c31ae2c145db1 5d2404d89a837f4d03d7 hobbit.tar.gz \ rmd160 82b9991f3bf0ceedbf74c1 88c5fa44b98b5e40c9 \ sha256 2c3afd16915e9f8eac2351 673f8b599f5fd2ff9064
5.3.5. Extract Phase Keywords The list of keywords related to the extract phase. extract.asroot
This keyword is used to specify that the extract phase should be done as the root user. Default: no Example:
extract.asroot
no
extract.suffix
This keyword is used to specify the extract suffix type. Default: .tar.gz Example:
extract.suffix
.tgz
use_7z
This keyword is for downloads that are compressed using the 7z algorithm. When invoked, it automatically sets:
extract.suffix = .7z extract.cmd = 7za Default: no Example:
use_7z
yes
use_bzip2
This keyword is for downloads that are tarred and bzipped. When invoked, it automatically sets:
extract.suffix = .tar.bz2 extract.cmd = bzip Default: no Example:
use_bzip2
yes
use_lzma
This keyword is for downloads that are compressed using the lzma algorithm. When invoked, it automatically sets:
extract.suffix extract.cmd
= .lzma = lzma
Default: no Example:
use_lzma
yes
use_zip
This keyword is for downloads that are zipped. When invoked, it automatically sets:
extract.suffix extract.cmd extract.pre_args extract.post_args
= = = =
.zip unzip -q "-d ${extract.dir}"
Default: no
https://guide.macports.org/#installing.macports.git
Page 39 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Example:
use_zip
yes
use_xz
This keyword is for downloads that are compressed using the xz tool. When invoked, it automatically sets:
extract.suffix extract.cmd
= .tar.xz = xz
Default: no Example:
use_xz
yes
extract.mkdir
This keyword is used to specify if the directory worksrcdir is part of t he distfile or if it should be created automatically and the distfiles should be extracted there instead. This is useful for distfiles with a flat structure which would pollute the worksrcdir with lots of files. Default: no Example:
extract.mkdir
yes
extract.only, extract.only-append, extract.only-delete
List of files to extract into ${worksrcpath}. Only use if default extract behavior is not correct for your port. Default: ${distfiles} Example:
extract.only
foo.tar.gz
extract.only-append extract.only-delete
bar.tar.gz foo.tar.gz
extract.cmd
Command to perform extraction. Default: gzip Example:
extract.cmd
gunzip
extract.args, extract.pre_args, extract.post_args
Main arguments to extract.cmd; additional arguments passed before and after the main arguments. Default: ${distpath}/${distfile} Example:
extract.args
${distpath}/${distfile}
The following argument modifiers are available:
extract.pre_args, defaults to: -dc extract.post_args, defaults to: "| tar -xf -" Examples:
extract.pre_args extract.post_args
xf "| gnutar -x"
5.3.6. Patch Phase Keywords The list of keywords related to the patch phase. patch.dir
Specify the base path for patch files. Default: ${worksrcpath} Example:
patch.dir
${worksrcpath}/util
patch.cmd
Specify the command to be used for patching files.
https://guide.macports.org/#installing.macports.git
Page 40 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: patch Example:
patch.cmd
cat
patchfiles, patchfiles-append, patchfiles-delete
Specify patch files to be applied for a port; list modifiers specify patchfiles to be added or removed from a previous patchfile declaration. Default: none Example:
patchfiles
patch-Makefile.in \ patch-source.c
patchfiles-append patchfiles-delete
patch-configure patch-src-Makefile.in
patch.args, patch.pre_args, patch.post_args
Main arguments to patch.cmd; optional argument modifiers pass arguments before and after the main arguments. Default: none Example:
patch.args
???
The following argument modifiers are available:
patch.pre_args, defaults to: -p0 patch.post_args, defaults to: none Examples:
patch.pre_args patch.post_args
-p1 ???
5.3.7. Configure Phase Keywords The list of keywords related to the configure phase. MacPorts base sets some important default configure options, so should use the -append version of most configure keywords so you don't overwrite them. For example, MacPorts base sets default configure.cflags so you should always use configure.cflags-append to set additional CFLAGS in Portfiles. use_configure
Sets if the configure phase should be run. Can be used if the port has no ./configure script. Default: yes Example:
use_configure
no
configure.cmd, configure.cmd-append, configure.cmd-delete
Selects the command to be run in the default configure phase. Default: ./configure Example:
configure.cmd
./config.sh
configure.env, configure.env-append, configure.env-delete
Set environment variables for configure; list modifiers add and delete items from a previous Portfile configure.env keyword, or a default set by MacPorts base. If available, it is encouraged to use the predefined options (like configure.cflags ) instead of modifying configure.env directly. Default: CFLAGS=-I${prefix}/include LDFLAGS=-L${prefix}/lib Example:
configure.env configure.env-append configure.env-delete
QTDIR=${prefix}/lib/qt3 ABI=32 TCLROOT=${prefix}
configure.optflags, configure.optflags-append, configure.optflags-delete
Set optimization compiler flags; list modifiers add or delete items from a previous Portfile configure.optflags keyword or the default set by MacPorts base. Default: -Os https://guide.macports.org/#installing.macports.git
Page 41 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Example:
configure.optflags
-O2
configure.optflags-append configure.optflags-delete
-finline-functions -Os
configure.cflags, configure.cflags-append, configure.cflags-delete
Set CFLAGS compiler flags; list modifiers add or delete items from a previous Portfile configure.cflags keyword or the default set by MacPorts base. Default: ${configure.optflags} Example:
configure.cflags
-Os -flat_namespace
configure.cflags-app end configure.cflags-delete
"-undefined suppress" -O2
configure.ldflags, configure.ldflags-append, configure.ldflags-delete
Set LDFLAGS compiler flags; list modifiers add or delete items from a previous Portfile configure.ldflags keyword or the default set by MacPorts base. Default: -L${prefix}/lib -Wl,-headerpad_max_install_names Example:
configure.ldflags
"-L${worksrcpath}/zlib -lz"
configure.ldflags-ap pend configure.ldflags-delete
"-L/usr/X11R6/lib -L${worksrcpath}/lib " -L${prefix}/lib/db44
configure.cppflags, configure.cppflags-append, configure.cppflags-delete
Set CPPFLAGS to be passed to the C processor; list modifiers add or delete items from a previous Portfile configure.cppflags keyword or the default set by MacPorts base. Default: -I${prefix}/include Example:
configure.cppflags
-I${worksrcpath}/include
configure.cppflags-a ppend configure.cppflags-delete
"-I/usr/X11R6/lib -I${worksrcpath}/lib -DHAVE -I${prefix}/lib/db44
configure.cxxflags, configure.cxxflags-append, configure.cxxflags-delete
Set CXXFLAGS to be passed to the C++ processor; list modifiers add or delete items from a previous Portfile configure.cxxflags keyword or the default set by MacPorts base. Default: ${configure.optflags} Example:
TODO: add example configure.objcflags, configure.objcflags-append, configure.objcflags-delete
TODO: add description Default: ${configure.optflags} Example:
TODO: add example configure.classpath, configure.classpath-append, configure.classpath-delete
TODO: add description Default: ??? Example:
TODO: add example configure.macosx_deployment_target, configure.macosx_deployment_target-append, configure.macosx_deployment_target-delete
TODO: add description Default: ??? Example:
TODO: add example configure.fflags, configure.fflags-append, configure.fflags-delete
https://guide.macports.org/#installing.macports.git
Page 42 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Set FFLAGS to be passed to the Fortran compiler; list modifiers add or delete items from a previous Portfile configure.fflags keyword or the default set by MacPorts base. Default: ${configure.optflags} Example:
configure.fflags
-Os
configure.fcflags, configure.fcflags-append, configure.fcflags-delete
Set FCFLAGS to be passed to the Fortran compiler; list modifiers add or delete items from a previous Portfile configure.fcflags keyword or the default set by MacPorts base. Default: ${configure.optflags} Example:
configure.fcflags
-Os
configure.f90flags, configure.f90flags-append, configure.f90flags-delete
Set F90FLAGS to be passed to the Fortran 90 compiler; list modifiers add or delete items from a previous Portfile configure.f90flags keyword or the default set by MacPorts base. Default: ${configure.optflags} Example:
configure.f90flags
-Os
configure.cc
Set CC compiler flags for selecting a C compiler. Default: ??? Example:
configure.cc
${prefix}/bin/gcc-mp-4.2
configure.cpp
Set CPP compiler flags for selecting a C preprocessor. Default: ??? Example:
configure.cpp
/usr/bin/cpp-3.3
configure.cxx
Set CXX compiler flags for selecting a C++ compiler. Default: ??? Example:
configure.cxx
/usr/bin/g++-4.0
configure.objc
Set OBJC compiler flags for selecting an Objective-C compiler. Default: ??? Example:
configure.objc
/usr/bin/gcc-4.0
configure.fc
Set FC compiler flags for selecting a Fortran compiler. Default: ??? Example:
configure.fc
${prefix}/bin/gfortran-mp-4.2
configure.f77
Set F77 compiler flags for selecting a Fortran 77 compiler. Default: ??? Example:
configure.f77
${prefix}/bin/gfortran-mp-4.2
configure.f90
Set F90 compiler flags for selecting a Fortran 90 compiler. https://guide.macports.org/#installing.macports.git
Page 43 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: ??? Example:
configure.f90
${prefix}/bin/gfortran-mp-4.2
configure.javac
Set JAVAC compiler flags for selecting a Java compiler. Default: ??? Example:
configure.javac
${prefix}/bin/jikes
configure.compiler
Select a compiler suite to fill the compiler environment variables. All variables/tools a compiler suite can provide are set. Manually set variables are not overwritten. Dependencies are not added for you, as they may be just build- or also run-dependencies. Keep in mind that not all compiler suites might be available on your platform: gcc-3.3 is available on Mac OS X 10.3 and 10.4 PowerPC, gcc-4.0 is available on 10.4+, gcc-4.2 and llvm-gcc-4.2 are available on 10.5 and 10.6, and clang is available on 10.6. Only use it if a port really needs a different compiler. Default: gcc-4.0 on Mac OS X 10.4 and 10.5 Default: gcc-4.2 with Xcode 3.2 on Mac OS X 10.6 Default: llvm-gcc-4.2 with Xcode 4.0 and 4.1 on Mac OS X 10.6 and 10.7 Default: clang with Xcode 4.2 and up on Mac OS X 10.6 and up Values: gcc-3.3 gcc-4.0 gcc-4.2 llvm-gcc-4.2 clang apple-gcc-4.0 apple-gcc-4.2 macports-gcc-4.1 macports-gcc-4.2 macports-gcc-4.3 macports-gcc-4.4 macports-gcc4.5 macports-gcc-4.6 macports-gcc-4.7 macports-gcc-4.8 macports-clang-2.9 macportsclang-3.0 macports-clang-3.1 macports-clang-3.2 Example:
configure.compiler
macports-gcc-4.5
configure.perl
Set PERL flag for selecting a Perl interpreter. Default: ??? Example:
configure.perl
${prefix}/bin/perl5.12
configure.python
Set PYTHON flag for selecting a Python interpreter. Default: ??? Example:
configure.python
${prefix}/bin/python2.7
configure.ruby
Set RUBY flag for selecting a Ruby interpreter. Default: ??? Example:
configure.ruby
${prefix}/bin/ruby
configure.install
Set INSTALL flag for selecting an install tool; used for copying files and creating directories. Default: /usr/bin/install Example:
configure.install
${prefix}/bin/ginstall
configure.awk
Set AWK flag for selecting an awk executable. Default: ??? Example:
configure.awk
https://guide.macports.org/#installing.macports.git
${prefix}/bin/gawk
Page 44 of 81
MacPorts Guide
22/09/17 8:30 p.m.
configure.bison
Set BISON flag for selecting a bison executable, a parser generator. Default: ??? Example:
configure.bison
/usr/bin/bison
configure.pkg_config
Set PKG_CONFIG flag for helping find pkg_config, a tool for retrieving information about installed libraries. Default: ??? Example:
configure.pkg_config
${prefix}/bin/pkg-config
configure.pkg_config_path
Set PKG_CONFIG_PATH flag for telling pkg_config where to search for information about installed libraries. Default: ${prefix}/lib/pkgconfig:${prefix}/share/pkgconfig Example:
configure.pkg_config_path
${python.prefix}/lib/pkgconfig
configure.args, configure.pre_args, configure.post_args
Main arguments to configure.cmd; optional argument modifiers pass arguments before and after the main arguments. Default: none Example:
configure.args
--bindir=${prefix}/bin
The following argument modifiers are available:
configure.pre_args, defaults to: --prefix=${prefix} configure.post_args, defaults to: none Examples:
configure.pre_args --prefix=${prefix}/share/bro configure.post_args OPT="-D__DARWIN_UNIX03" 5.3.7.1. Configure Universal
Universal keywords are used to make a port compile on OS X for multiple architectures.
Note There is a default universal variant made available to all ports by MacPorts base, so redefining universal keywords should only be done to make a given port compile if the default options fail to do so.
configure.universal_args
Arguments used in the configure script to build the port universal. Default: --disable-dependency-tracking Example:
TODO: add example configure.universal_cflags
Additional flags to put in the CFLAGS environment variable when invoking the configure script. Default value is based on ${configure.universal_archs}. Default: (PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc (Intel Tiger / Leopard) -arch i386 -arch ppc (Snow Leopard and later) -arch x86_64 -arch i386 Example:
TODO: add example
https://guide.macports.org/#installing.macports.git
Page 45 of 81
MacPorts Guide
22/09/17 8:30 p.m.
configure.universal_cppflags
Additional flags to put in the CPPFLAGS environment variable when invoking the configure script. Default: (PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk (others) none Example:
TODO: add example configure.universal_cxxflags
Additional flags to put in the CXXFLAGS environment variable when invoking the configure script. Default value is based on ${configure.universal_archs}. Default: (PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc (Intel Tiger / Leopard) -arch i386 -arch ppc (Snow Leopard and later) -arch x86_64 -arch i386 Example:
TODO: add example configure.universal_ldflags
Additional flags to put in the LDFLAGS environment variable when invoking the configure script. Default: (PowerPC Tiger) -Wl,-syslibroot,${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 arch ppc (Intel Tiger / Leopard) -arch i386 -arch ppc (Snow Leopard and later) -arch x86_64 -arch i386 Example:
TODO: add example 5.3.7.2. Automake, Autoconf, and Autoreconf
The list of configure keywords available for ports that need automake and/or autoconf. use_autoreconf
Whether or not to use autoreconf Default: no Example:
use_autoreconf
yes
use_automake
Whether or not to use automake. Default: no Example:
use_automake
yes
automake.env
Environment variables to pass to automake. Default: ??? Example:
automake.env
CFLAGS=-I${prefix}/include
automake.args
Arguments to pass to automake. Default: ??? Example:
automake.args
--foreign
automake.dir
Directory in which to run ${automake.cmd}.
https://guide.macports.org/#installing.macports.git
Page 46 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: ${worksrcpath} Example:
automake.dir
./src
use_autoconf
Whether or not to use autoconf. Default: no Example:
use_autoconf
yes
autoconf.env
Environmental variables to pass to autoconf. Default: ??? Example:
autoconf.env
CFLAGS=-I${prefix}/include/gtk12
autoconf.args
Arguments to pass to autoconf. Default: ??? Example:
autoconf.args
"-l src/aclocaldir"
autoconf.dir
Directory in which to run ${autoconf.cmd}. Default: ${worksrcpath} Example:
autoconf.dir
src
5.3.8. Build Phase Keywords The list of keywords related to the build phase. build.cmd
Make command to run in ${worksrcdir}. Only use it if you can't use build.type. Default: make Example:
build.cmd
scons
build.type
Defines which build software is required and sets ${build.cmd} accordingly. The available options are BSD Make, GNU Make, and Xcode. Default: default (the default Make on the current platform) Values: default bsd gnu xcode Example:
build.type
bsd
build.args, build.pre_args, build.post_args
Main arguments to ${build.cmd}; optional argument modifiers pass arguments before and after the main arguments. Default: none Example:
build.args
-DNOWARN
The following argument modifiers are available:
build.pre_args, defaults to: ${build.target} build.post_args, defaults to: none Examples:
https://guide.macports.org/#installing.macports.git
Page 47 of 81
MacPorts Guide
22/09/17 8:30 p.m.
build.pre_args build.post_args
-project AudioSlicer.xcode CFLAGS_SYS="-DUSE_FREET YPE -DPREFER_FREETYPE"
build.target, build.target-append, build.target-delete
Build target to pass to ${build.cmd}; list modifiers add or delete items from a previous Portfile build.target keyword or the default set by MacPorts base. Default: all Example:
build.target
all-src
build.target-append build.target-delete
doc extra compat
build.env, build.env-append, build.env-delete
Set environment variables for build; list modifiers add and delete items from a previous Portfile build.env keyword, or a default set by MacPorts base. Default: none use_parallel_build
This keyword is for specifying whether or not it is safe for a port to use multiple CPUs or multiple cores in parallel during its build phase. If use_parallel_build is not set to “no” in a given port, the option -j${build.jobs} is passed to ${build.cmd} (if ${build.cmd} is make or scons). Default: yes Example:
use_parallel_build
no
build.jobs
The number of simultaneous jobs to run when parallel build is enabled. The default value is based on the variable buildmakejobs in macports.conf. Default: If buildmakejobs is 0, the number of CPU cores in the machine, or the number of GB of physical memory plus one, whichever is less. Otherwise, the actual value of ${buildmakejobs}.
5.3.9. Test Phase Keywords The list of keywords related to the test phase. test.run
Enable running test suites bundled with a port. Default: no Example:
test.run
yes
test.cmd
Test command to run relative to ${worksrcdir}. Default: ${build.cmd} Example:
test.cmd
checks.sh
test.target
Test target to pass to ${test.cmd}. Default: test Example:
test.target
checks
test.args, test.pre_args, test.post_args
Main arguments to test.cmd ; optional argument modifiers pass arguments before and after the main arguments. Default: none Example:
test.args
-f Makefile.test
The following argument modifiers are available:
test.pre_args, defaults to: ${test.target} https://guide.macports.org/#installing.macports.git
Page 48 of 81
MacPorts Guide
22/09/17 8:30 p.m.
test.post_args, defaults to: none test.env, test.env-append, test.env-delete
Set environment variables for test; list modifiers add and delete items from a previous Portfile test.env keyword, or a default set by MacPorts base. Often DYLD_LIBRARY_PATH is set here to support testing dynamically linked libraries. Default: none Example:
test.env
DYLD_LIBRARY_PATH=${worksrcpath}/src/.libs
5.3.10. Destroot Phase Keywords The list of keywords related to the destroot phase. destroot.cmd
Install command to run relative to ${worksrcdir}. Default: ${build.cmd} Example:
destroot.cmd
scons
destroot.args, destroot.pre_args, destroot.post_args
Main arguments to ${destroot.cmd}; optional argument modifiers pass arguments before and after the main arguments. Default: none Example:
destroot.args
BINDIR=${prefix}/bin
The following argument modifiers are available:
destroot.pre_args, defaults to: ${destroot.target} destroot.post_args, defaults to: ${destroot.destdir} Examples:
destroot.pre_args destroot.post_args
-project AudioSlicer.xcode INSTDIR=${destroot}${prefix}
destroot.target, destroot.target-append, destroot.target-delete
Install target to pass to ${destroot.cmd}; list modifiers add or delete items from a previous Portfile destroot.target keyword or the default set by MacPorts base. Default: install Example:
destroot.target
install install-config install-commandmode
destroot.target-append destroot.target-delete
install-plugins install-commandmode
destroot.destdir
Arguments passed to ${destroot.cmd} via ${destroot.post_args} to install correctly into the destroot. Default: DESTDIR=${destroot} Example:
destroot.destdir
prefix=${destroot}${prefix}
Note If an application's Makefile properly supports the DESTDIR variable, MacPorts will automatically destroot the port properly. A port must destroot properly or the port will not install correctly, upgrade, or uninstall. If not, you may need to set this variable, or even patch the application's Makefile.
destroot.umask
Umask to use during destroot. Default: 022 https://guide.macports.org/#installing.macports.git
Page 49 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Example:
destroot.umask
002
destroot.keepdirs
A list of directories that should not be removed if empty upon destroot completion. Default: ??? Example:
destroot.keepdirs
${destroot}${prefix}/va r/run \ ${destroot}${prefix}/va r/log \ ${destroot}${prefix}/var/cache/mrtg
destroot.violate_mtree
MacPorts tests for compliance to the common directory structure in ${prefix}. If a port is not compliant with the standard, set it to yes. You can find the macports standard in MacPorts File Hierarchy or in the porthier(7) man page. If destroot.violate_mtree is set to yes, the following warning is issued during the installation.
Warning: portname requests to install files outside the common directory struct This means that the port installed files outside of their normal locations in ${prefix}. These could be files totally outside of ${prefix}, which could cause problems on your computer, or files inside of ${prefix} that are not in a standard location. Use port contents portname to see the location for all files that were installed by a given port. Default: no Example:
destroot.violate_mtree
yes
5.4. Dependencies Free and open source software is highly modular, and MacPorts ports often require that other ports be installed beforehand; these prerequisites for a given port are called a port's “dependencies”. The keywords used when specifying dependencies in a Portfile are related to port install phases, and they refer to what are called library, build, fetch, extract and run dependencies. Though all of them install dependencies before a given port is installed, specifying dependencies with the correct keyword is important for proper port upgrade and uninstall behavior, or when running targets other than install. For example, you may not uninstall a port that is a library dependency for another installed port, though you may remove one that is a build dependency. Likewise, if you run the fetch target for a port, only the fetch dependencies will be installed first, so they should be all that is needed for that target. depends_fetch, depends_fetch-append, depends_fetch-delete
The list of dependencies to check before phases fetch, checksum , extract, patch, configure, build, destroot, install, and package. Fetch dependencies are needed to download the distfiles for a port, and are not needed at all once the software is installed. depends_extract, depends_extract-append, depends_extract-delete
The list of dependencies to check before phases extract, patch, configure, build, destroot, install, and package. Extract dependencies are needed to unpack a port's distfiles into the work directory, and are not needed at all once the software is installed. depends_build, depends_build-append, depends_build-delete
The list of dependencies to check before phases configure, build, destroot, install, and package. Build dependencies are needed when software is being built, but not needed at all once it is installed. depends_lib, depends_lib-append, depends_lib-delete
The list of dependencies to check before phases configure, build, destroot, install, and package. Library dependencies are needed both at build time (for headers and libraries to link against) and at run time. depends_run, depends_run-append, depends_run-delete
The list of dependencies to check before phases destroot, install, and package. Run dependencies are needed when the software is run, but not to compile it.
5.4.1. Port and File Dependencies There are two types of dependencies: port dependencies and file dependencies. Port dependencies can be satisfied by reference to a port (the MacPorts registry is queried), or by reference to a file (whether provided by a port or not). The most commonly-used type of dependencies in Portfiles are port dependencies, because dependencies should be provided by MacPorts ported software whenever possible, and usually only one port can provide the needed libraries and files. But when satisfying a dependency with vendor-supplied software is preferred for special reasons, or when it is possible for more than one port to satisfy a dependency, then file dependencies may be used. An example of the former is with ubiquitous utilities like awk, grep, make or sed, where OS X's versions are often sufficient; an example of the latter is with “-devel” ports —these ports provide a different version of the same files (though only one can be activated at a time). Port dependencies, the preferred type, are specified as shown in these examples:
depends_lib https://guide.macports.org/#installing.macports.git
port:rrdtool port:apache2 Page 50 of 81
MacPorts Guide
22/09/17 8:30 p.m.
depends_build
port:libtool
depends_run
port:apache2 port:php5
File dependencies should only be used if one of the reasons listed above applies. There are three types: bin for programs, lib for libraries, and path for any installed file. File dependencies are specified in the form: : : . For bin dependencies, is the name of a program in a bin directory like ${prefix}/bin, /usr/bin, /bin, and the associated sbin directories. For lib dependencies, is the name of a library (but without its extension) in a lib directory like ${prefix}/lib, /usr/lib, /lib, some Framework directories, and those found in environment variables like DYLD_LIBRARY_PATH. For path dependencies, is the complete absolute path to the file, or more usually, when the file is inside ${prefix}, it is specified relative to ${prefix}. Since path dependencies are the only ones which would find files only in an absolute path or a path inside ${prefix} they are - in cases when a port needs to be more restrictive - often used instead of bin and lib dependencies . Note that the specified is only installed if the specified library, binary, or file is not found. See the examples below:
depends_lib
lib:libX11.6:xorg
depends_build
bin:glibtool:libtool
depends_run
path:lib/libltdl.a:libtool
5.5. Variants MacPorts variants are conditional modifications of port installation behavior during port installation. There are two types of variants: user-selected variants and platform variants. User-selected variants are options selected by a user when a port is installed; platform variants are selected automatically by MacPorts base according to the OS or hardware platform (darwin, freebsd, linux, i386, powerpc, etc.).
5.5.1. User-Selected Variants User-selected variants are those that are defined so a user can invoke them to enable port options at install time. They also allow a port author a level of modularity and control using the keyword default_variants (see below).
Note Variant names may contain only letters, numbers and underscore characters. In particular, the hyphen is not a valid character in variant names because it would conflict with the notation for deselecting a variant.
variant name [requires variant1 variant2 ...] [conflicts variant1 variant2 ...] [description description]
The variant declaration may contain any keywords that can be placed in a Portfile's global section. If you wish to execute system (shell) calls or Tcl extensions during the execution of a port phase, you should place those statements within a variant_isset conditional within a phase declaration and not within the variant declaration itself. Dependencies and conflicts with other variants in the same port can be expressed with requires and conflicts options as shown below. Default: none Examples:
variant gnome requires glib { configure.args-appen d --with-gnome depends_lib-append port:gnome-session } variant apache2 conflicts apache { configure.args-appen d \ --with-apxs2=${prefix}/apache2/bin/apxs } default_variants
The optional default_variants keyword is used to specify variants that a port author wishes to have enabled by default. This allows for Portfile modularity and also allows users to suppress default variants if they wish. Default: none Example:
default_variants
+ssl +tcpd
Default variants may be suppressed by preceding a variant name with a “-” as shown in this example.
https://guide.macports.org/#installing.macports.git
Page 51 of 81
MacPorts Guide
22/09/17 8:30 p.m.
%% port install foo -ssl universal_variant
When using MacPorts on OS X, a universal variant is defined by default to configure ports with universal flags. The variant can be overridden if the default code does not work (see the Configure Universal section above), or suppressed if a universal variant does not function properly for a given port. Default: yes Example:
universal_variant
no
5.5.2. User-Selected Variant Descriptions User-selected variants ought to provide a description, which will be displayed when using command port variants foo. The syntax used for the description keyword is shown below.
variant bar description {Add IMAP support} {} Descriptions should be short but clear, and not merely repeat the name of the variant. To allow for compatibility for possible MacPorts GUI support, a good rule of thumb is to use sentence fragments for brevity, with a capitalized first letter and no trailing punctuation. Think of them as short labels such as ones you'd find next to a GUI checkbox or radio button. Thus, it would be better to write “Build with support for foo” instead of “Builds with support for foo”; “Add support for foo” would be better than “Adds support for foo”. Variant descriptions are strings, so one should take care not to put whitespace between the brackets and the beginning and end of the variant description, and also not to use unnecessary whitespace, unlike with port descriptions and long_descriptions.
5.5.3. Platform Variants Platform variants are either defined by default in MacPorts base, or defined by a port author to customize a port's installation according to OS (operating system) or hardware platform. platform os [version] [arch]
MacPorts allows platform-specific port options to be specified in a Portfile for handling differences between platforms and versions of the same platform.
platform darwin version can be used to handle different tasks depending on the version of Darwin, the core operating system underlying OS X. version is the major version of Darwin, and can be 8 for Mac OS X 10.4 Tiger, 9 for 10.5 Leopard, 10 for 10.6 Snow Leopard or 11 for 10.7 Lion. Examples:
platform darwin 10 { configure.env-append LIBS=-lresolv } platform darwin i386 { configure.args-appen d --disable-mmx } platform darwin 8 powerpc { configure.compiler gcc-3.3 }
Note Though a combination of OS version and hardware platform may be specified in a single platform statement (e.g., darwin 8 i386), it is not possible to specify a range of platforms with a single statement. For example, to select Darwin versions 9 and 10 while excluding all others, you would need two statements: platform darwin 9 and platform darwin 10. Alternately, you could make that behavior the port's default, and add a platform darwin 8 block to remove it again.
5.6. Tcl Extensions & Useful Tcl Commands A MacPorts Portfile is a Tcl script, so it may contain any arbitrary Tcl code you may learn about in a Tcl reference manual. However, few authors will use arbitrary Tcl code; the vast majority will use a subset of Tcl commands and a number of Tcl extensions that are coded within MacPorts for performing the most common tasks needed for Portfiles. The list below is a list of useful Tcl commands for Portfile development and Tcl extensions provided by MacPorts base. file
The standard Tcl file command can be used for a number of operations on files, such as moving, renaming, deleting, or creating directories, among others. For a complete list, consult the Tcl reference manual for the file command, or the Tcl file manpage in the n section of manpages on your machine using man n file file copy
Copy a file. https://guide.macports.org/#installing.macports.git
Page 52 of 81
MacPorts Guide
22/09/17 8:30 p.m.
file rename
Rename a file. file delete [-force]
Remove a file or (with -force ) a directory and its contents. file mkdir
Create a directory. macros
For the above operations provided by Tcl's file command, MacPorts provides the following shorthands. These used to be separate functions to work around bugs in older Tcl versions or on old versions of OS X. Nowadays those are simple aliases. copy
Shorthand alternative to file copy. move
Shorthand alternative to file rename. delete file ...
Deletes each of the given files/directories. Behaves similarly to file delete -force except that file delete -force will fail to delete directories properly on 10.3 systems. touch
Mimics the BSD touch command. ln
Mimics the BSD ln command. xinstall
xinstall copies files and creates directories; it is intended to be compatible with install(1). xinstall [-o owner ] [-g group ] [-m mode ] [file1 file2 ...] directory
Install the specified file(s) to a destination directory. xinstall [-o owner ] [-g group ] [-m mode ] [-W dir ] [file1 file2 ...] directory
Change to dir and install file(s) to a destination directory. xinstall [-o owner ] [-g group ] [-m mode ] {*}[glob pattern] directory
Install the file(s) matching the glob pattern to a destination directory. Note the use of the {*} operator to convert the list returned by glob into separate arguments to xinstall. xinstall -d [-o owner ] [-g group ] [-m mode ] directory
Create a directory including parent directories if necessary. Defaults: owner group mode - 0755 Examples:
xinstall -m 640 ${worksrcpath}/README \ ${destroot}${prefix}/share/doc/${name} xinstall -m 640 -W ${worksrcpath}/doc README INSTALL COPY \ ${destroot}${prefix}/share/doc/${name} xinstall -m 640 {*}[glob ${worksrcpath}/doc/*] \ ${destroot}${prefix}/share/doc/${name} xinstall -d ${destroot}${prefix}/share/doc/${name} strsed
strsed can be used for string manipulations using regular expressions. It supports a small subset of the commands known from sed(1). strsed string s/ regex / replacement /
Replaces the first instance of regex with replacement. Refer to re_format(7) for a definition of regular expression syntax. strsed string g/ regex / replacement /
The same as the previous format, except all instances of the pattern will be replaced, not only the first (mnemonic: 'g' is for global). reinplace
https://guide.macports.org/#installing.macports.git
Page 53 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Allows text specified by a regular expression to be replaced by new text, in-place (the file will be updated itself, no need to place output into a new file and rename). reinplace [-locale locale ] [-n] [-W dir ] [--] command file ...
Replace text given by the regular expression portion of the command with the replacement text, in all files specified. Use -locale to set the locale. The default locale is en_US.UTF-8. For example, -locale C will allow a nonUTF-8 file to be modified (which may otherwise give the error "sed: RE error: illegal byte sequence"), but only operating on ASCII characters. If you need it to work on non-ASCII characters you need to set a locale with the correct charset for the file, e.g. "en_US.ISO8859-1". -n is passed to sed to suppress echoing result -W to set a common working directory for multiple files Use -E to use the extended regular expression style (see re_format(7) for a description of the basic and extended styles) Use -- to end option processing and allow any further dashes not to be treated as options. Examples:
reinplace -W ${worksrcpath} "s|/usr/local|${prefix}|g" configure setup.py reinplace "s|@@PREFIX@@|${prefix}|g" ${worksrcpath}/Makefile user/group passwd adduser username [uid= uid ] [gid=gid ] [passwd= ] [realname=realname ] [home=home ] [shell=shell]
Add a new local user to the system with the specified uid, gid, password, real name, home directory and login shell. existsuser username
Check if a local user exists. Returns the uid for the given user, or 0 if the user wasn't found. Checking for the root user is not supported because its uid is 0, and it will always exist anyway. nextuid
Returns the highest used uid plus one. passwd addgroup group [gid=gid ] [passwd= ] [realname=realname ] [users=users]
Add a new local group to the system, with the specified gid, password, real name, and with a list users as members. existsgroup group
Check if a local group exists and return the corresponding gid. This can be used with adduser:
addgroup foo adduser foo gid=[existsgroup foo] nextgid
Returns the highest used gid plus one. External program execution
Use only when ....
5.7. StartupItems A StartupItem is a MacPorts facility to run “daemons,” a Unix term for programs that run continuously in the background, rather than under the direct control of a user; for example, mail servers, network listeners, etc. Ports that use StartupItem keywords create OS X scripts for launchd, which is the Apple facility introduced with Mac OS X 10.4 to replace xinetd for starting and managing daemons. To support launchd , a program named daemondo is provided by MacPorts base that serves as an adapter between OS X's launchd and daemons (“executable” StartupItems) or traditional Unix startup scripts that start daemons (“script” StartupItems). There are three categories of StartupItem keywords. Those that trigger StartupItem creation and logging, those that specify attributes of “executable” StartupItems, and those that specify attributes of “script” StartupItems.
Note The variable startupitem_type in ${prefix}/etc/macports/macports.conf may be set to none to globally override all StartupItem keywords found in Portfiles; this prevents StartupItems from being created.
5.7.1. StartupItem Attributes The keywords in this section may be used with either “executable” or “script” StartupItems (see below). startupitem.create
https://guide.macports.org/#installing.macports.git
Page 54 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Trigger the creation of a StartupItem. Default: no Example:
startupitem.create
yes
startupitem.name
Sets the name for the StartupItem. Defaults to the name of the port, so this keyword is usually unnecessary. Default: ${name} Example:
startupitem.name
dhcpd
startupitem.logfile
Path to a logfile for logging events about the lifetime of the StartupItem. Depending on the type of StartupItem, and the manner in which it is started, standard output from the daemon may also be directed to the logfile. Default: /dev/null Example:
startupitem.logfile
${prefix}/var/log/mydaemon.log
startupitem.logevents
Control whether or not to log events to the log file. If logevents is set, events with timestamps are logged to the logfile. Default: no Example:
startupitem.logevents
yes
startupitem.netchange
Cause the daemon to be restarted when a change in network state is detected. Default: no Example:
startupitem.netchange
yes
5.7.2. Executable StartupItems Daemons run continuously, so monitoring the health of daemon processes and restarting them if they die is an important StartupItems' feature. “Executable” StartupItems are preferred over “script” StartupItems because daemondo launches the daemon directly , rather than indirectly via a script, and therefore it automatically knows how to monitor a daemon process and restart it if it dies. Daemons used with “executable” StartupItems may be programs or scripts (shell, perl, python, etc.) as long as the script itself is the daemon, rather than merely what launches the daemon. In the latter case “script” StartupItems are to be used.
Note Since “script” and “executable” are mutually exclusive StartupItem types, the startupitem.executable keyword may not be used in a Portfile that uses any keywords listed in the Script StartupItems section.
startupitem.executable
Specifies the name of the daemon to be run. It may have multiple arguments, but they must be appropriate for a call to exec; arbitrary shell code may not be used.
Note Some daemons “daemonize” by detaching themselves from the controlling tty before sending themselves to the background, thus making themselves a child of the original process. A daemon to be started with startupitem.executable must not be allowed to do this or daemondo will think the process has died and start multiple instances. Often daemons have a command switch to run in the foreground, and this method should be used for daemons that detach.
Default: none Example:
https://guide.macports.org/#installing.macports.git
Page 55 of 81
MacPorts Guide
22/09/17 8:30 p.m.
startupitem.executab le
${prefix}/sbin/vm-pop3d -d 10 -t 600
Note Do not wrap values in quotes if passing arguments to the daemon; “executable” StartupItem elements must be tagged individually so the spaces between arguments serve as delimiters for “string” tags. For example, this startupitem key/value pair:
startupitem.executable
${prefix}/sbin/vm-pop3d -d 10 -t 600
generates a .plist file with these tags:
ProgramArguments /opt/local/bin/daemondo --label=vm-pop3d --start-cmd /opt/local/sbin/vm-pop3d -d 10 -t 600 ;
5.7.3. Script StartupItems StartupItems of type “script” create a wrapper during port installation for daemondo that will be used to launch a daemon startup script present in an application's source distribution (MacPorts does not create daemon startup scripts) for daemons that require a script.
Note “Executable” StartupItems are the preferred type since “script” StartupItems launch daemons indirectly , and this requires that port authors use the startupitem.pidfile keyword so that daemondo can check this pid file to see is a daemon process has died and restart it. Any time a script (or an executable) itself serves as a daemon, use the “executable” StartupItem type so daemondo will launch it directly and track its health automatically. Additionally, since “script” and “executable” are mutually exclusive StartupItem types, the startupitem.executable keyword may not be used in a Portfile that uses “script” StartupItem keywords.
A typical snippet of a startup script that may be used with a “script” StartupItem is shown below. Notice that the script is not a daemon; rather the script indirectly launches the vm-pop3d daemon.
#!/bin/sh case "$1" in start) echo -n "Starting vm-pop3d: " /opt/local/sbin/vm-pop 3d -d 10 -t 600 [... trimmed ...] startupitem.start, startupitem.stop, startupitem.restart
Specify a shell script to start, stop, and restart the daemon. In the absence of startupitem.restart, the daemon will be restarted by taking the stop action, followed by the start action. Default: none Examples:
startupitem.start startupitem.stop startupitem.restart
"${prefix}/share/mysql/ mysql.server start" "${prefix}/share/mysql/ mysql.server stop" "${prefix}/share/mysql/ mysql.server restart"
Note Wrap the stop, start, and restart values in quotes so they will be placed in the wrapper tagged as a single element.
startupitem.init
Shell code that will be executed prior to any of the options startupitem.start, startupitem.stop and startupitem.restart. https://guide.macports.org/#installing.macports.git
Page 56 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: none Example:
startupitem.init
BIN=${prefix}/sbin/bacula-fd
startupitem.pidfile
This keyword must be defined properly for daemondo to be able to monitor daemons launched via “script” StartupItems and restart them if they die. It specifies two things: a process id (PID) file handling method, and a pidfile name and path. Default: none ${prefix}/var/run/${name}.pid Default: [none] | [${prefix}/var/run/${name}.pid] Values [none auto manual clean] [ /path/to/pidfile ] Example:
startupitem.pidfile
auto ${prefix}/var/run/${na me}.pidfile
PID file handling options:
none - daemondo will not create or track a PID file, so it won't know when a daemon dies. auto - The started process is expected to create a PID file that contains the PID of the running daemon; daemondo then reads the PID from the file and tracks the process. The started process must delete the PID file if this is necessary. clean - The started process is expected to create a PID file that contains the PID of the running daemon; daemondo then reads the PID from the file and tracks the process, and deletes the PID file if it detects the daemon has died. manual - This option should only be used if an “executable” StartupItem could be used (daemondo launches a daemon directly) and a port author wants a PID file written for some special use. A PID file is not needed to detect process death for daemons launched directly by daemondo. As with executable StartupItems, daemondo remembers the PID of the launched process and tracks it automatically.
5.7.4. Loading / Unloading StartupItems into launchd A port with a StartupItem places a link to a .plist file for the port's daemon within /Library/LaunchDaemons/. A .plist file is an XML file; MacPorts installs .plist files tagged as “disabled” for the sake of security. You may enable a startup script (tag the.plist file as “enabled”) and load it into launchd with a single command as shown.
%% sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist You may stop a running startup script, disable it (tag the.plist file as “disabled”), and unload it from launchd with a single command as shown.
%% sudo launchctl unload -w /Library/LaunchDaemons/org.macports.mysql5.plist
5.7.5. StartupItem Internals During port installation a MacPorts StartupItem creates a .plist file in ${prefix}/etc/LaunchDaemons/, and places a symbolic link to the .plist file within /Library/LaunchDaemons/. For example, the StartupItem for the mysql5 port is org.macports.mysql5.plist, and it is linked as shown.
%% ls -l /Library/LaunchDaemons org.macports.mysql5.plist -> /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist For “script” StartupItems, in addition to a .plist file, a wrapper is also created.
%% ls -l /opt/local/etc/LaunchDaemons/org.macports.mysql5/ -rwxr-xr-x -rw-r--r--
2 root 2 root
wheel wheel
475 Aug 975 Aug
2 14:16 mysql5.wrapper 2 14:16 org.macports.mysql5.pli st
The wrapper manipulates the script as specified in the startupitem.start and startupitem.stop keywords. An example wrapper script snippet is shown below.
#!/bin/sh # MacPorts generated daemondo support script # Start Start() { /opt/local/share/mysql5 /mysql/mysql.server start } # Stop Stop() { /opt/local/share/mysql5 /mysql/mysql.server stop
https://guide.macports.org/#installing.macports.git
Page 57 of 81
MacPorts Guide
22/09/17 8:30 p.m.
} [... trimmed ...]
5.8. Livecheck / Distcheck Options livecheck and distcheck are especially useful for port maintainers, but others may also find this information valuable. Livecheck checks to see if MacPorts can query the developer's download site to determine if a newer version of the software has become available since the port was installed. livecheck.type
Specify what kind of update check to perform. Open source mirror site options are to use the project's latest file release from sourceforge or googlecode, or the project's date_updated XML tag for freecode. These options are automatically used if a matching ${master_sites} URL is used. Generic download site options are to specify a moddate (modification date of a URL resource), a regex (retrieve the version by applying a regex to a URL resource), regexm (retrieve the version by applying a multi-line regex to a URL resource), md5 (compares the md5 sum of a URL resource) or none (no check). Default: sourceforge or googlecode if the ${master_sites} is one of these, else freecode. Values: freecode sourceforge googlecode moddate regex regexm md5 none Examples:
livecheck.type livecheck.url livecheck.regex
regex ${homepage} "Generally Available (\\d+(?:\\.\\d+)*)"
livecheck.name
Name of the project for live checks. Is only used with freecode, sourceforge, and googlecode livechecks. Default: ${name} or the sourceforge, freecode or googlecode project name if it can be guessed from ${master_sites}. Example:
livecheck.name
hibernate
livecheck.distname
Name of the file release for sourceforge and googlecode checks. For sourceforge releases use the name of the package release. For googlecode releases use the name of the file download, including extension. You may use this keyword without livecheck.version if you replace the version part of the name with “ (.*)”. Default: sourceforge: ${livecheck.name}, googlecode: first ${distfiles} item Example:
livecheck.distname
faad2.src
livecheck.version
Version of the project for a check; used for regex-based checks. Default: ${version} Example:
livecheck.version
${name}-${version}
livecheck.url
URL to query for a check. Default:
${homepage} or the first hit among the following sites: http://freecode.com/projects-xml/${livecheck.name}/${livecheck.name}.xml http://sourceforge.net/api/file/index/project-name/${livecheck.name}/rss http://code.google.com/p/${livecheck.name}/downloads/list Example:
livecheck.url
http://ftp.gnu.org/gnu/bison/
livecheck.regex
Regular expression to parse the resource for regex checks. Be sure to use a regular expression grouping around the version component. Also remember that square brackets need to be quoted because Tcl otherwise interprets them as a procedure call. Default: none
https://guide.macports.org/#installing.macports.git
Page 58 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Example:
livecheck.regex
4th-(\[a-z0-9.\]+)-unix${extract.suffix}
livecheck.md5
md5 checksum to use for an md5 comparison. Default: none Example:
livecheck.md5
37e6a5b6516a680c7178b72021d3b706
Distcheck reports whether or not the distfile(s) specified in a Portfile are still available on the developer's download site. Examples are given below. distcheck.check
This option can be used to disable distcheck. It specifies what kind of check should be performed on distfiles: moddate (check if the Portfile is older than the distfile) or none (no check). Default: moddate Example:
distcheck.check
none
5.9. PortGroups 5.9.1. PortGroup Introduction PortGroups are simply include files for portfiles. They can define as much or as little as a portgroup author feels is necessary to provide a set of definitions or behaviors common to a group of portfiles, in order that those portfiles can be expressed as simply as possible with minimum redundancy. See the following folder for PortGroup definitions:
${prefix}/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/ A sample listing follows:
%% ls -1 /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_ archcheck-1.0.tcl cmake-1.0.tcl crossbinutils-1.0.tcl gnustep-1.0.tcl haskell-1.0.tcl hocbinding-1.0.tcl hunspelldict-1.0.tcl kde4-1.0.tcl kde4-1.1.tcl . . . The requirements of a minimum portfile using a portgroup varies by portgroup. The sections below devoted to each portgroup (or, for portgroups not documented there yet, the comments in the header of the portgroup file itself) should provide guidance on how each portgroup is used. Prospective MacPorts developers are also encouraged to examine existing portfiles that use these portgroups.
5.9.2. PortGroup gnustep PortGroup gnustep allows for efficient porting of GNUstep-based open source software using the GNU objective-C runtime that defines options for the configuration, build, and destroot phases, and also defines some values for GNUstep-based software. A minimum Portfile using the gnustep PortGroup class need only define the fetch and the checksum phases. 5.9.2.1. gnustep PortGroup Specific Keywords
Portfiles using the gnustep PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. gnustep.post_flags
An associative array which specifies the sub-directories relative to ${worksrcpath} and the SHARED_LD_POSTFLAGS variables to be added to GNUmakefile.preamble in those sub-directories. This helps making the patching process easier on Darwin. Type: optional Default: none Example:
platform darwin { https://guide.macports.org/#installing.macports.git
Page 59 of 81
MacPorts Guide
22/09/17 8:30 p.m.
array set gnustep.post_flags { BundleSubDir "-lfoo -lbar" } } gnustep.cc
Define the gcc compiler to use when compiling a port. Type: optional Default: gcc-mp-4.2 Example:
gnustep.cc gcc-mp-4.3 variant with_docs
Many GNUstep packages include a Documentation sub-directory that is not built by default. Enabling this variant builds and installs the included documentation. Type: optional Example:
%% port install gnustep-gui +with_docs 5.9.2.2. gnustep FilesystemLayout Keywords
PortGroup gnustep supports both the traditional gnustep file layout and the new fhs file layout. However, a given ported application does not necessarily support both. The Portfiles have access to many procedures to handle these two layouts: set_gnustep_make
Sets GNUSTEP_MAKEFILES according to the FilesystemLayout set_gnustep_env
Sets DYLD_LIBRARY_PATH and PATH for the gnustep FilesystemLayout gnustep_layout
Returns true (1) if current file layout is gnustep set_system_library
Sets GNUSTEP_SYSTEM_LIBRARY according to the FilesystemLayout set_local_library
Sets GNUSTEP_LOCAL_LIBRARY according to the FilesystemLayout 5.9.2.3. gnustep PortGroup Sugar
Portfiles using PortGroup gnustep do not need to define the following variables: categories
Default: gnustep homepage
Default: http://www.gnustep.org/ master_sites
Default: gnustep:core depends_lib
Default: gnustep-core use_configure
Default: no configure.env
Default: DYLD_LIBRARY_PATH PATH configure.pre_args-append
Default: CC=gcc-mp-4.2 GNUSTEP_MAKEFILES build.type
Default: gnu build.env
Default: DYLD_LIBRARY_PATH PATH build.pre_args-append
Default: messages=yes destroot.env
Default: DYLD_LIBRARY_PATH PATH https://guide.macports.org/#installing.macports.git
Page 60 of 81
MacPorts Guide
22/09/17 8:30 p.m.
destroot.pre_args-append
Default: messages=yes
5.9.3. PortGroup haskell PortGroup haskell simplifies the addition of Haskell packages. 5.9.3.1. haskell PortGroup Specific Keywords
Portfiles using the haskell PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. haskell.setup
This keyword sets a number of port variables. Type: required Synopsis: the first argument is the package name, as called by hackageDB; the second is the version number Example:
haskell.setup
digest 0.0.0.2
5.9.3.2. haskell PortGroup Sugar
Portfiles using PortGroup haskell do not need to define the following variables: name
Default: hs-[string tolower ${package}] version
Default: ${version} (from haskell.setup) categories
Default: devel haskell homepage
Default: http://hackage.haskell.org master_sites
Default: ${homepage}/packages/archive/${package}/${version} distname
Default: ${package}-${version} depends_build
Default: ghc configure, build, and destroot phases
Default: proper setup to run these phases post-destroot
Default: creates and installs (into destroot) the register.sh and unregister.sh scripts post-activate
Default: runs the register.sh scripts livecheck
Default: runs livecheck against the package's information page
5.9.4. PortGroup perl5 PortGroup perl5 allows for efficient porting of perl modules and other perl open source software. 5.9.4.1. perl5 PortGroup Specific Keywords
Portfiles using the perl5 PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. perl5.setup
This keyword sets the ${distfile} and ${version}. Type: required Example:
perl5.setup
Net-Telnet 3.03
perl5.use_module_build
Perl modules are ordinarily assumed to be built with ExtUtils::MakeMaker. Use this keyword if a module must be built
https://guide.macports.org/#installing.macports.git
Page 61 of 81
MacPorts Guide
22/09/17 8:30 p.m.
using Module::Build instead. Type: optional Example:
perl5.use_module_build 5.9.4.2. perl5 PortGroup Sugar
Portfiles using PortGroup perl5 do not need to define the following variables: categories
Default: perl master_sites
Default: http://search.cpan.org/dist/${distname} depends_lib
Default: perl5.8 use_configure
Default: no 5.9.4.3. perl5 PortGroup Specific Variables
When the perl5 PortGroup is declared within a Portfile, the following variables are provided during port install. perl5.version
The MacPorts Perl version. perl5.bin
The Perl binary path (i.e., ${prefix}/bin/perl). perl5.lib
Path to the Perl vendor directory. perl5.archlib
Path to the Perl architecture-dependent modules directory.
5.9.5. PortGroup python PortGroup python allows for efficient porting of python-based open source software.
Note A number of python-version-specific PortGroups also exist, such as python27 and python32. These should not be used for new development, and ports using them should be migrated to the unified python PortGroup.
5.9.5.1. python PortGroup Specific Keywords
Portfiles using the python PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords. python.versions
Defines the python versions supported by this port. If the port name starts with “py-”, then a subport will be defined for each version in the list. For example, if a port named “py-foo” declares python.versions 26 27, subports “py26foo” and “py27-foo” will be created, and will depend on python26 and python27 respectively. If the port name does not start with “py-”, it is interpreted as an application written in python rather than a python module. In this case, no subports are defined, and python.versions defaults to the value of python.default_version, which must be set. For example, if a port named “mercurial” sets python.default_version 27, then python.versions will automatically be set to “27”, and a dependency on python27 will be added. Type: required for modules, optional for apps Example:
python.versions
25 26 27
python.default_version
For modules (i.e., name starts with “py-”), this sets the subport that will be installed if the user asks to install “py-foo” rather than, e.g., “py26-foo” or “py27-foo”. If not explicitly set, a reasonable default is chosen from the list in python.versions. For applications (i.e., name does not start with “py-”), this chooses which version of python to use, and must be set. It can be changed in variants if desired. https://guide.macports.org/#installing.macports.git
Page 62 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Type: required for apps, optional for modules Example:
python.default_version
32
python.link_binaries
When “yes” (the default), tells the PortGroup to automatically link any executable binaries installed in the bin/ directory within the framework into ${prefix}/bin. Type: optional Example:
python.link_binaries
no
python.link_binaries_suffix
Suffix to add to the names of the links created in ${prefix}/bin when ${python.link_binaries} is enabled. Can be cleared if no suffix is desired. Type: optional Default: -${python.branch} python.add_archflags
When yes (the default), the PortGroup will automatically try to pass the correct arch-specific flags during build time (via the standard CFLAGS, LDFLAGS, etc environment variables). Set this to “no” and set up those variables in build.env manually if the default does not work. Type: optional Example:
python.add_archflags
no
5.9.5.2. python PortGroup Specific Variables
When the python PortGroup is declared within a Portfile, the following variables are provided. python.version
The python version in use in the current subport. This will be one of the versions listed in python.versions. python.branch
The python version in use in the current subport, in normal dotted notation. For example, if python.version is “26”, python.branch will be “2.6”. python.prefix
The prefix in which the current python version is installed. For framework builds, this is ${frameworks_dir}/Python.framework/Versions/${python.branch}, whereas for non-framework builds, it is the same as ${prefix}. python.bin
The path to the MacPorts Python executable. python.lib
The Python dynamic library path, i.e., ${python.prefix}/Python (framework builds) or ${prefix}/lib/libpython2.4.dylib (python24). python.libdir
The path to python's lib directory, i.e., ${python.prefix}/lib/python${python.branch}. python.include
Path to the Python include directory. python.pkgd
Path to the Python site-packages directory. (i.e., ${python.prefix}/lib/python${python.branch}/sitepackages). 5.9.5.3. python PortGroup Sugar
Portfiles using PortGroup python do not need to define the following variables: categories
Default: python depends_lib
Default: port:python${python.version} use_configure
Default: no build.cmd
https://guide.macports.org/#installing.macports.git
Page 63 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: ${python.bin} setup.py --no-user-cfg build.target
Default: build destroot.cmd
Default: ${python.bin} setup.py --no-user-cfg destroot.destdir
Default: --prefix=${python.prefix} --root=${destroot} pre-destroot
Default: creates directory ${destroot}${prefix}/share/doc/${subport}/examples.
5.9.6. PortGroup ruby PortGroup ruby allows for efficient porting of ruby-based open source software. 5.9.6.1. ruby PortGroup Specific Variables
When the ruby PortGroup is declared within a Portfile, the f ollowing variables are provided during port install. ruby.version
The MacPorts Ruby version. ruby.bin
The Ruby binary location. ruby.lib
Path to the Ruby vendorlibdir directory (i.e., ${prefix}/lib/ruby/vendor_ruby/${ruby.version}) ruby.arch
The name for the Ruby architecture-dependent directory name (i.e., i686-darwin8.10.1). ruby.archlib
Path to the Ruby vendor archdir (i.e., ${ruby.lib}/${ruby.arch}).
5.9.7. PortGroup xcode PortGroup xcode allows for efficient porting of Xcode-based opensource software. A minimum Portfile for PortGroup xcode uses defaults for the configuration, build, and destroot phases. It also defines some values for Xcode-based software. Using PortGroup xcode is a way to make your port able to tolerate Xcode version updates because the PortGroup is tested against all supported OS X and Xcode versions. 5.9.7.1. xcode PortGroup Specific Keywords
Portfiles using PortGroup xcode allow for port authors to set the following keywords in addition to t he general Portfile keywords. xcode.project
The path relative to ${build.dir} and ${destroot.dir} of the Xcode project. If unset, Xcode Tools should be able to determine it automatically. It usually succeeds if there is only a single project in the directory. Type: optional Default: none Example:
xcode.project ${name}.xcode xcode.configuration
Project configuration/buildstyle to use. Type: optional Default: Deployment Example:
xcode.configuration Main xcode.target
If present, it overrides build.target and destroot.target. Type: optional Default: none Example:
xcode.target ${name}
https://guide.macports.org/#installing.macports.git
Page 64 of 81
MacPorts Guide
22/09/17 8:30 p.m.
xcode.build.settings
Additional settings passed to the xcode build tool during the build phase. These settings should be in the X=Y form. Type: optional Default: none Example:
xcode.build.settings FRAMEWORK_SEARCH_PATHS=${frameworks_dir} xcode.destroot.type
Type of project that will be installed. This tells the xcode PortGroup how to destroot the project. Correct values are application and framework. Type: optional Default: application Example:
xcode.destroot.type framework xcode.destroot.path
Where to install the build product. Type: optional Default: ${frameworks_dir} or ${applications_dir} depending on xcode.destroot.type. xcode.destroot.settings
Additional settings passed to the xcode build tool during the destroot phase. These settings should be in the X=Y form. Type: optional Default: none Example:
xcode.destroot.settings SKIP_INSTALL=NO xcode.universal.settings
Settings passed to the xcode build tool when the +universal variant is selected. These settings should be in the X=Y form. Type: optional Default: ARCHS="${universal_archs}" MACOSX_DEPLOYMENT_TARGET=${universal_target} xcode.universal.sdk
SDK to use when the +universal variant is selected. The argument may be an absolute path to an SDK, or the canonical name of an SDK. Type: optional Default: ${universal_sysroot} 5.9.7.2. xcode PortGroup Sugar
Portfiles using the xcode PortGroup do not need to define the following variables: categories
Default: aqua platforms
Default: macosx use_configure
Default: no 5.9.7.3. Portfile-Phase Keywords Affecting the xcode PortGroup
The following Portfile phase keywords affect the xcode PortGroup in a unique way. In most cases, you will not need to set any of these keywords in the Portfile. See portfile-phase(7) build.cmd
Default: ${xcodebuildcmd}. build.target
Default: "" This variable will be ignored if xcode.target is set. build.args https://guide.macports.org/#installing.macports.git
Page 65 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: build destroot.cmd
Default: ${xcodebuildcmd} destroot.target
Default: "" This variable will be ignored if xcode.target is set.
Chapter 6. MacPorts Internals This chapter contains information about the MacPorts file layout, configuration files, a few fundamental port installation concepts, and the MacPorts APIs.
6.1. File Hierarchy Name porthier — layout of the ports filesystems
Description A map of the filesystem hierarchy used by MacPorts and the ports it installs. Much of it is based on hier(7).
${prefix} The base of the MacPorts filesystem hierarchy. Default: /opt/local/
bin/ Common utilities, programming tools, and applications.
etc/ System configuration files and scripts.
include/ Standard C include files.
lib/ Archive libraries.
libexec/ System daemons and system utilities (executed by other programs).
Library/Frameworks/ Native Mac OS X Library Frameworks
sbin/ System programs and administration utilities.
share/ Architecture-independent files.
doc/ Miscellaneous documentation.
examples/ Examples for users and programmers.
info/ GNU Info hypertext system.
locale/ Localization files.
man/
https://guide.macports.org/#installing.macports.git
Page 66 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Manual pages.
misc/ Miscellaneous system-wide ASCII text files.
src/ Source code.
var/ Multi-purpose log, temporary, transient and spool files.
db/ Miscellaneous automatically generated system-specific database files.
macports/ MacPorts package building topdir.
build/ Where ports are built and destrooted.
distfiles/ Storage location for the distfiles of fetched ports.
packages/ Obsolete. Formerly contained archives (packages) of installed ports.
receipts/ Obsolete. Formerly contained the registry information and receipts for installed ports, in flat-file format.
registry/ Contains the registry database in sqlite format.
software/ The files for each installed port are stored here.
sources/ Holds the sources for the ports tree (the Portfiles) and also MacPorts base.
spool/ Directory containing output spool files.
log/ Miscellaneous system log files.
run/ System information files describing various information about the system since it was booted.
www/ Files to be served by an http server.
cgi-bin/ Directory for cgi executables.
/Applications/MacPorts/ Native Mac OS X applications.
SEE ALSO port(1), macports.conf(5), portfile(7), portgroup(7), portstyle(7), hier(7)
AUTHORS Felix Kroniage Juan Manuel Palacios
6.2. Configuration Files The MacPorts configuration files often do not need to be modified for the general end user. They contain options that may be of use to advanced users and port developers. Some automatically configured options may need to be updated when migrating to a new CPU architecture or a new OS version. There are three MacPorts configuration files that define important variables used by the MacPorts system: macports.conf, sources.conf, and variants.conf. All MacPorts configurations files are located in ${prefix}/etc/macports.
https://guide.macports.org/#installing.macports.git
Page 67 of 81
MacPorts Guide
22/09/17 8:30 p.m.
MacPorts configuration file format is a simple key/value pair separated by either a space or a tab. Lines beginning with '#' are comments, empty lines are ignored.
6.2.1. macports.conf macports.conf is the configuration file used to bootstrap the MacPorts system. This file is read by the port command and determines how it behaves. Options locating other .conf files. sources_conf
Where to find the sources list. Default: ${prefix}/etc/macports/sources.conf variants_conf
Where to find global variants definition file (optional). Default: ${prefix}/etc/macports/variants.conf Options for MacPorts general operating characteristics. prefix
Sets the directory where ports are installed. Any path may be used but those with spaces and/or non-ASCII characters should be avoided because it can break some ports. Default: /opt/local portdbpath
Directory where MacPorts keeps working data as downloaded sources, installed port receipts, and the main registry. Same path restrictions apply as for '${prefix}'. Default: ${prefix}/var/macports portdbformat
Formerly selected the storage type to use for the MacPorts registry: flat or sqlite. Currently, only sqlite can be used. Default: sqlite build_arch
The machine architecture to build for in normal use. Options include: ppc, i386, ppc64, x86_64 Default: (Snow Leopard and later) x86_64 or i386 depending on hardware (Leopard/Tiger) i386 or ppc depending on hardware applications_dir
Directory to install MacPorts that install OS X .app bundles. Default: /Applications/MacPorts frameworks_dir
Directory to install fr ameworks installed by ports. Default: ${prefix}/Library/Frameworks developer_dir
Directory where Xcode is installed. Default: /Developer buildfromsource
Controls whether ports are built from source or downloaded as pre-built archives. Setting to 'always' will never use archives, 'never' will always try to use an archive and fail if one is not available. 'ifneeded' will try to fetch an archive and fall back to building from source if that isn't possible. Default: ifneeded portarchivetype
Format of archives in which to store port images. This controls both the type of archive created locally after building from source, and the type to request from remote servers. Changing this will not affect the usability of already installed archives; they can be of any supported type. Supported types are: tgz, tar, tbz, tbz2, tlz, txz, xar, zip, cpgz, cpio Default: tbz2 configureccache
Use ccache (C/C++ compiler cache) - see http://ccache.samba.org/ Default: no configuredistcc
Use distcc (distributed compiler) - see http://distcc.samba.org/ Default: no configurepipe
Use pipes rather than intermediate files when compiling C/C++/etc https://guide.macports.org/#installing.macports.git
Page 68 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Default: yes buildnicevalue
Lowered scheduling priority (0-20) to use for make when building ports. Default: 0 buildmakejobs
Number of simultaneous make jobs (commands) to use when building ports. Using “0” will cause a runtime autodetection to use all available processor cores. Default: 0 portautoclean
Set whether to automatically execute “clean” after “install” of ports. Default: yes rsync_server
Rsync server from which to fetch MacPorts sources. Default: rsync.macports.org rsync_dir
Rsync directory from which to pull the base/ component (infrastructure) of MacPorts. Default: release/tarballs/base.tar rsync_options
Rsync options Default: -rtzv --delete-after destroot_umask
Umask value to use during the destrooting or a port. Default: 022 binpath
Sets env(PATH), the directory search path for locating system executables (rsync, tar, etc.) during port installation. Only applications in these directories are available while ports are being installed even if other paths are specified by $PATH in a user's environment. Default: ${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin
Note The binpath is implicitly defined, but it may be overwritten by defining the variable in macports.conf. However, using a non-default binpath is discouraged and should only be performed by advanced users.
host_blacklist
Space separated list of download hosts that should not be used. Default: none
Note This feature is especially useful if a host turns out to be consistently slow and therefore should be excluded for MacPorts' actions.
preferred_hosts
Space separated list of download hosts that should be used preferentially. Default: none revupgrade_autorun
Controls whether the rev-upgrade action will be run automatically after upgrading ports. Default: yes revupgrade_mode
Controls the rev-upgrade functionality which checks for broken linking and can rebuild ports to fix it. 'rebuild' means ports will automatically be rebuilt when broken linking is detected in their files, while 'report' means broken files will be scanned for and reported but the ports will not be rebuilt. Default: rebuild Options for MacPorts Universal Binaries (+universal variant) universal_archs
https://guide.macports.org/#installing.macports.git
Page 69 of 81
MacPorts Guide
22/09/17 8:30 p.m.
The machine architectures to use for +universal variant (multiple entries must be space delimited). Options include: ppc, i386, ppc64, x86_64 Default: x86_64 i386 (ppc i386 for 10.5 and earlier) Options for StartupItems startupitem_type
Options for generated startup items, though this may be overridden by the startupitem.type Portfile key. Options are “default” option, “SystemStarter”, “launchd”, or “none”. For an empty or “default” option, a startupitem type appropriate to the platform is used; if “none”, no port startupitems are installed. Default: default Other options extra_env
Extra environment variables to keep. Any variables listed here are added to the list of variables that are not removed from the environment used while processing ports. Default: none place_worksymlink
Set whether to place a symlink named “work” from your ports tree to the build directory of a port, when the port is being built. This is convenient, but may not be ideal if you care about the structure of your ports tree. For example, some developers keep their ports tree synchronized across multiple computers, and don't want to also synch build directories. Default: yes
6.2.2. sources.conf This file enables rsync synchronization of the default ports tree with the MacPorts rsync server when either of the commands port selfupdate or port sync are run. Default: rsync://rsync.macports.org/release/tarballs/ports.tar [default] Optional local repositories are enabled using a file url: file:///path/to/localportsrepository
6.2.3. variants.conf This optional file specifies any variants you'd like to be invoked globally. If a variant specified in this file is not supported by a given Portfile, the variant is simply ignored. Default: none
6.3. Port Images MacPorts has a unique ability to allow multiple versions, revisions, and variants of the same port to be installed at the same time, so you may test new port versions without uninstalling a previous working version. This capability derives from the fact that a MacPorts port by default is not installed into its final or “activated” location, but rather to an intermediate location that is only made available to other ports and end-users after an activation phase that extracts all its files from the image repository. Deactivating a port only removes the files from their activated locations (usually under ${prefix}) —the deactivated port's image is not disturbed. The location of an installed port's image can be seen by running:
%% port location PORTNAME
6.4. APIs and Libs The MacPorts system is composed of three Tcl libraries: MacPorts API - MacPorts public API for handling Portfiles, dependencies, and registry Ports API - API for Portfile parsing and execution pextlib - C extensions to Tcl
6.4.1. Ports API The code for the Port API is located in base/src/port1.0. The Port API provides all the primitives required for a Portfile to be parsed, queried, and executed. It also provides a single procedure call that the MacPorts API uses to kick off execution: eval_targets. The port Tcl library supplies these procedures, all of which are generated at run-time using the options procedure in portutil.tcl. The macports Tcl library loads the Portfile into a sub-interpreter, within which all port-specific code is run. This process ensures that there will never be pollution of the Tcl space of other ports, nor the MacPorts libraries, nor the calling application.
Note
https://guide.macports.org/#installing.macports.git
Page 70 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Portfiles are executed in a Tcl interpreter as Tcl code (and not truly parsed strictly speaking), so every Portfile option must be a Tcl procedure.
The Ports API performs the following functions: Manages target registrations. All targets register themselves with the Port API. Accordingly, the Port API creates pre/post-/main overrides for each of the targets. Option/Default handling. All Portfile options (name, version, revision ...) are registered by targets. The Port API creates procedures for these options, and sets up the complex variable traces necessary to support option defaults. Executes target procedures, including the pre/post/main routines. Manages a state file containing information about what variants were specified and what targets have run successfully. Provides essential Portfile Tcl extensions (reinplace, xinstall, etc). Provides simple access to the ui_event mechanism by providing the various ui_ procedures (i.e., ui_msg, ui_error).
6.4.2. MacPorts API The code for the MacPorts API is located in base/src/macports1.0. The MacPorts API provides a public API into the MacPorts system by providing simple primitives for handling Portfiles, dependencies, and registry operations, and exports the MacPorts API for the port command line utility, or any other. The API has very little information about the contents Portfiles; instead, it relies entirely upon the port Tcl library. By keeping the high level API simple and generic, revisions to the underlying ports system will not necessarily require a revision of the high level MacPorts API. The MacPorts API is also responsible for loading user specified options into a sub-interpreter to be evaluated by the ports API. In that case it sets the variable name in the sub-interpreter and adds the option to the sub-interpreter's global array user_options(). User options are passed as part of the call to mportopen. The MacPorts API performs the following functions: Dependency support. This is implemented in a highly generic fashion, and is used throughout the system. The dependency functions are exported to the Port API, and the Port API uses them to execute targets in the correct order. Dependency processing. Software dependencies are handled at this layer using the dependency support layer. UI abstractions. UI Abstractions are handled at this layer. Each port action is provided a context, and a mechanism for posting user interface events is exported to the Port API (ui_event). Registry management routines. Manages the SQLite port registry in ${prefix}/var/macports/registry/. See also Section 6.5, “The MacPorts Registry”. Exports the MacPorts API for use by client applications. The following routines are defined.
mportinit: Initializes the MacPorts system. Should be called before trying to use any other procedure. mportsearch: Given a regexp, searches the PortIndex for ports with matching names. mportopen: Given a URI to a port, opens a Portfile and returns an opaque handle to it. mportclose: Given a port handle, closes a Portfile. mportexec: Given a port handle, executes a target ( e.g., install). mportinfo: Given a port handle, this returns the PortInfo array (as a flat list of array elements). This is a little tricky and unstable and only used by portindex. mportdepends: Given a port handle, returns a list of ports upon which the specified port depends. For an example of the MacPorts API, when one executes port search cm3, the port utility: Calls the mportsearch function to find all ports containing “cm3”. Returns Tcl array(s) containing data from the PortIndex: port name, version, revision, variants, etc. Formats the list of arrays in the standard viewing format. For another MacPorts API example, when one executes port install cm3, the port utility: Calls the mportsearch function to find the first port that matches the name “cm3”. Calls the mportopen function to open the port. Calls the mportexec function to execute the install target in the port. Calls the mportclose function to close the port.
6.4.3. pextlib The pextlib Tcl library provides a variety of C extensions to add capabilities to Tcl procedures; for example, an interface to flock(2) and mkstemp(3).
https://guide.macports.org/#installing.macports.git
Page 71 of 81
MacPorts Guide
22/09/17 8:30 p.m.
6.5. The MacPorts Registry This chapter provides an overview of the MacPorts registry and its API. The registry is queried by MacPorts utilities for information about installed ports related to dependencies, dependencies, port images, and simple user information about what is installed. It provides abstraction over a modular receipt storage layer; where the default format is a SQLite database. The registry allows MacPorts utilities to: Modify receipts to reflect changes made to installed ports being maintained by MacPorts. Query the global file and dependency databases for file conflicts between a port being installed and a port already installed. Maintain dependency trees of installed ports.
6.5.1. Registry Files The SQLite registry used by default is located at ${portdbpath}/registry, which by default would be ${prefix}/var/macports/registry. All data is stored in a single file named registry.db, although the additional directory portfiles is used temporarily for extracting stored Portfiles from the registry. Furthermore, access to the registry may be locked using .registry.lock with the registry::exclusive_lock and registry::exclusive_unlock APIs. The legacy flat file registry files are contained in ${portdbpath}/receipts, which by default is location ${prefix}/var/macports/receipts. File mappings and dependency mappings are tracked in the flat file registry by file_map.db and dep_map.bz2. If found, these will be automatically converted to the new SQLite registry.
6.5.2. The Registry API The MacPorts registry provides a public API in the registry1.0 Tcl package. Using this API listed below you can access the MacPorts Registry using the default receipt storage mechanism chosen in macports.conf.
registry::new_entry registry::new_entry {name version {revision 0} {variants ""}} Begin the creation of a new registry entry for the given port. Returns a reference ID to the registry entry created.
registry::open_entry registry::open_entry {name {version 0} {revision 0} {variants ""}} Opens an existing registry entry. Returns a reference ID to the registry entry that was opened.
registry::entry_exists registry::entry_exists {name version {revision 0} {variants ""}} Checks to see if a port exists in the registry. Returns 1 if the entry exists, 0 if not.
registry::write_entry registry::write_entry {ref} Writes the receipt associated with the given reference.
registry::delete_entry registry::delete_entry {ref} Deletes the receipt associated with the given reference.
registry::property_store registry::property_store {ref property value} Store the given value with the property name in the receipt associated with the given reference.
registry::property_retrieve registry::property_retrieve {ref property} Retrieve the property name from the receipt associated with the given reference. Returns the value of the property, if the property exists.
registry::installed registry::installed {{name ""} {version ""}} Get all installed ports, optionally all installed ports matching the given name, or the given name and version. Returns a list of the installed ports.
registry::location registry::location {portname portversion} Returns the physical location the port is installed in on the disk. This is primarily useful for finding out where a port image is installed.
registry::open_file_map registry::open_file_map {args} Opens the file map that contains file-port relationships.
registry::file_registered registry::file_registered {file} Returns the name of the port that owns the given file, if the file is registered as installed, and 0 otherwise.
registry::port_registered registry::port_registered {name} Returns a list of all files associated with the given port if that port is installed, and 0 otherwise.
registry::register_file registry::register_file {file port} Registers the given file in the file map as belonging to the given port.
registry::unregister_file registry::unregister_file {file} Removes the file from the file map.
https://guide.macports.org/#installing.macports.git
Page 72 of 81
MacPorts Guide
22/09/17 8:30 p.m.
registry::write_file_map registry::write_file_map {args} Write the changes to the file map.
registry::open_dep_map registry::open_dep_map {args} Opens the dependency map that contains port dependency relationships.
registry::fileinfo_for_file registry::fileinfo_for_file {fname} Returns a list for the given file name representing all data currently known about the file. This is a 6-tuple in the form of: 1. file path 2. uid 3. gid 4. mode 5. size 6. md5 checksum
registry::fileinfo_for_inde registry::fileinfo_for_index x {flist} Returns a list of information concerning each file in the given file list, if that file exists in the registry. The information if obtained through registry::fileinfo_for_file registry::fileinfo_for_file
registry::list_depends registry::list_depends {name} Returns a list of all the ports that given port name depends on.
registry::list_dependents registry::list_dependents {name} Returns a list of all the ports that depend on the given port name.
registry::register_dep registry::register_dep {dep type port} Registers the given dependency as the given type of dependency with the given port.
registry::unregister_dep registry::unregister_dep {dep type port} Unregister the given dependency of the given type as a dependency of the given port.
registry::write_dep_map registry::write_dep_map {args} Write changes to the dependency map.
Chapter 7. MacPorts Project 7.1. Using Trac for Tickets The MacPorts Project uses a system called Trac Trac to to file tickets to report bugs and enhancement requests. Though anyone may search Trac for tickets, you must have a GitHub account in account in order to login to Trac Trac to to create tickets.
7.1.1. Before Filing a New Ticket Clean and try again If a build fails or is otherwise interrupted, interrupted, and you try again, MacPorts tries to pick up where it left off. Sometimes this causes new problems, and even if it doesn't, it means that log messages from earlier steps, which can be essential for figuring out why a build failed, are not included in the new log; MacPorts prints “Skipping completed” in the log for each previously-completed phase that was skipped. Before filing a ticket, sudo port clean the port that failed, then try again. Check the problem hotlist The Problem Hotlist contains Hotlist contains possible solutions to problems that affect many MacPorts users. If a solution to your problem listed there works, don't file a ticket. Search to see if a Trac ticket has already been filed Avoid filing duplicate bugs. Search for duplicates by: using the search bar that appears on each page using the search page browsing the list of categorized reports making an advanced search by constructing a custom query Is the problem an application error and not related to compiling and installing? In general, application bugs should be reported to the developers of the app (“upstream”), not MacPorts. An
https://guide.macports.org/#installing.macports.git
Page 73 of 81
MacPorts Guide
22/09/17 8:30 p.m.
application bug that affects a large number of MacPorts users might merit a MacPorts bug for informational purposes only, but this should be done sparingly. Is the problem with a 'port upgrade' operation? If so, try a 'port uninstall foo ' and then reinstall. You might also want to run 'port -nR upgrade --force foo ' to rebuild ports depending upon port foo . Note that it is safest and recommended that most users always upgrade with 'port upgrade outdated' to update all ports at once. Upgrading a single port can lead to software errors in other ports that have not yet been upgraded.
7.1.2. Creating Trac Tickets Once you are logged into Trac, you may click New Ticket and Ticket and you will be presented with a new ticket window shown in the graphic below. Follow the Trac ticket guidelines below to fill out the form. If you are reporting a failed port install and a log was mentioned in the error, please use the I have files to attach to this ticket checkbox to add that log file to the ticket.
7.1.3. Trac Ticket Guidelines This is a short overview of the guidelines for Trac tickets. Please see below for longer and more detailed explanations.
TL;DR Field
Content
Summary $port $version [$variants]: short problem summary Example: openssl @1.0.1e_1+universal: DTLS handshake error messages with openconnect Description Describe your problem. Preformatted text (such as terminal output) should be put in {{{three curly brackets }}}. Please attach large amounts of output rather than pasting. Use the preview button! Type
Bugs, build failures, documentation fixes Improving existing work Update requests or patch submissions for ports Submission of new Portfiles Requests for new ports
Priority
Use normal or low. High is reserved for MacPorts developers.
Milestone
Leave empty.
Component
https://guide.macports.org/#installing.macports.git
defect enhancement update submissions request
base guide ports server/hosting website wiki
Tickets affecting MacPorts itself Use for documentation Tickets affecting specific ports. Remember to set the port field! Use for infrastructure issues Enhancements and fixes for the web site Enhancements Enhancements and fixes for the wiki (or just edit it directly!)
Page 74 of 81
MacPorts Guide
22/09/17 8:30 p.m.
Version
The version of MacPorts you are running.
Keywords
maintainer if you are the port's maintainer. haspatch if you are attaching a patch. Full list. list.
Port
The name of the port affected by this ticket. Separate multiple using spaces. Leave empty for non-port tickets.
Owner/ Cc Cc
Full email address or GitHub username of the port's maintainer. Run port info - to look this up. Do not add maintainer > or >. For ports with multiple maintainers, only put the first maintainer into the Owner field and all others in the Cc field. You do not need to Cc yourself.
There are certain conventions used to ensure that Trac tickets convey as much accurate information as possible so problems and contributions may be acted upon efficiently. Summary: [port] [version] [concise description]
Example: "rrdtool @1.2.23 +python Configure error - build failure" Description: All details that might be relevant to someone reading the ticket. Be sure to mention the versions of your operating system and Xcode install. Wiki formatting should formatting should be used to ensure that text is formatted correctly. Use the Preview button before submitting. If you want to post preformatted text such as a log or terminal output, make sure you use {{{...}}} around the text or it could break the page layout. Example:
{{{ your error message here
}}} Submitters are advised to trim inline pastes and logs to what's really relevant to the report, as otherwise overly large ticket pages can become unmanageable. Long output, such as the full log from a port build, should be added as an attachment, not pasted inline. See I have files to attach to this ticket below. Type: There are five types of tickets. defect - The default; any port/MacPorts build/runtime failures and/or documentation corrections. enhancement - Tickets, with or without patches, created to enhance something that isn't failing its intended purpose. update - Tickets, with or without patches, involving updating a port to a newer upstream version. submission - Tickets created to submit Portfiles for software not currently available in MacPorts. request - Tickets created to request the creation of a new port. Priority: Assign a priority level to the ticket. High - Reserved for the use of MacPorts team members, as they are the best fit to determine which reports warrant a higher priority over others.
requests, non-critical port failures. Normal - The default. For normal port failures, non-critical enhancement requests, Low - For mostly cosmetic improvements, documentation corrections/improvements, etc. Not set - Anything that doesn't fit the categories high, normal, or low. Milestone: Leave this blank. MacPorts developers will set this to the version of MacPorts that contains a fix for the ticket when they commit a change. Note that this is only meaningful for changes in MacPorts itself, since changes to ports are continuously provided to users. If the milestone is MacPorts Future no version of MacPorts with the fix has been released yet. Component: Set what part of the MacPorts Project the ticket is to be filed against. base - Tickets related to MacPorts base code. guide - Documentation enhancements and error corrections, or patches to the MacPorts Guide. ports - Tickets related to ports. server/hosting - For MacPorts hosting & server-side issues. website - MacPorts website enhancements and error corrections. wiki - MacPorts Wiki enhancements and error corrections. Version: Select the MacPorts version you are using when it is applicable. Keywords: Type any keywords that might help when searching for tickets. It is not useful to list words here that already appear elsewhere in the ticket. Keywords also serve as tags; for example, use “tiger” if reporting a bug that only affects OS X 10.4, “haspatch” if a fix is attached to the ticket, “maintainer” if you are the port's maintainer, or “LP64” if reporting an issue that only affects 64-bit platforms.
See the TicketsKeywordGuidelines wiki page for page for a clickable list of all keywords. keywords. Cc: Anyone else besides the ticket reporter and assignee who would like to be kept involved in the development of the ticket. Multiple email addresses or GitHub usernames should be separated with a comma and a space (e.g., neverpanic, [email protected], [email protected], [email protected] [email protected]).
When reporting port-related tickets, make sure you add the port maintainers email address or GitHub username to the Cc: field so they are notified of the ticket (unless you have commit access, then see Assign To: below). You can obtain the email address or GitHub username of the port maintainer by running port info --maintainers [port] Assign To: Only users with commit access can edit this field. If this is not you, see the section on the Cc field above. https://guide.macports.org/#installing.macports.git
Page 75 of 81
MacPorts Guide
22/09/17 8:30 p.m.
For tickets on ports, enter the email address or GitHub username of the port's maintainer (use port info [port] to find this). If multiple maintainers are listed, enter the first maintainer's email address or GitHub username here and enter the remaining maintainers' email addresses or GitHub usernames in the Cc field. Exclude the email address if it appears. If the maintainer's email address is , leave the field blank. Port: For tickets on ports, enter the name of the port (or ports, space-separated, when multiple are affected). I have files to attach to this ticket: Use this checkbox to attach files to the ticket immediately after you create it. Or you can attach files later using the Attach File button.
If the file you are attaching is larger than 256 KiB, please compress it with bzip2 or gzip first to save space on the server and bandwidth for those downloading it, as Trac will not preview files above that size anyway.
7.2. Contributing to MacPorts You may contribute new ports and enhancements of any kind to already existing ports using Trac tickets. As an alternative, you may instead open a pull request on GitHub, in which case no Trac ticket is required.
7.2.1. New Ports Ports are contributed by following these steps. See the Ticket Submission Guidelines for a description of all fields. 1. Please run
%% port lint --nitpick $portname where $portname is the name of the port you are submitting. Please fix any warnings and errors. 2. Either create a Trac ticket ... a. Set the type to submission . b. Set the component to ports. c. Set the port field to the name of the new port. d. Attach the Portfile and any required patchfiles to the ticket. 3. ... or submit the port update through a pull request on GitHub. 4. If your ticket or pull request doesn't receiv e any attention within a few days you may send an email to and request a review and/or commit. Please include a link to the ticket or pull request.
7.2.2. Port Enhancements Enhancements to existing ports may comprise new functionality for a given port, bug fixes or even simple version updates. They should always be contributed as patches against the current Portfile . See the Ticket Submission Guidelines for a description of all fields. 1. Create a Portfile patch with your changes. See Portfile Development for more information on how to edit Portfiles. 2. Please run
%% port lint --nitpick $portname where $portname is the name of the port you modified. Please fix any warnings and errors before submitting your changes. 3. Either create a Trac ticket ... a. Set the type to enhancement for miscellaneous enhancements, to defect for bug fixes, or to update for version updates. b. Set the component to ports. c. Set the port field to the name of the port you want to change. d. Put the maintainer's email address or GitHub username into the Cc field. You can use
%% port info --maintainer $portname where $portname is the name of the port you want to modify. Note that and are not real people and should thus not be Cc'd. e. Attach your Portfile patch file and any new or changed patch files to the ticket. 4. ... or submit the new port through a pull request on GitHub. 5. If your ticket or pull request doesn't receiv e any attention within a few days you may send an email to and request a review and/or commit. Please include a link to the ticket or pull request.
7.2.3. Becoming a Port Maintainer MacPorts is always looking for people that want to take care of a certain package. If you notice an outdated port, a bug in a port or simply a port without maintainer that you are interested in, feel free to volunteer as maintainer. To become a maintainer you need: An email address or a GitHub account. A copy of the Portfile. Do not worry if you don't know where to find one yet. There's more documentation on that https://guide.macports.org/#installing.macports.git
Page 76 of 81
MacPorts Guide
22/09/17 8:30 p.m.
below. An account in the MacPorts Trac, preferably with the email address you want to use for your port. Interest in the software you want to maintain and some time. You do not need: Commit access to the MacPorts repository. Instead, you create patches and open tickets in Trac. You can, however, apply for commit access once you have some experience in maintaining ports. In fact, we would like to encourage you to apply after a few months. Expert knowledge of the software you want to maintain or experience in Portfile programming. You can pick those up along the way. Your knowledge about the software you want to maintain is probably more than what most other MacPorts developers have, given the number of ports MacPorts has. Consult Chapter 4, Portfile Development chapter and Chapter 5, Portfile Reference on how to write a Portfile . If your questions are not answered there, please ask on the mailing list. To become the maintainer of a port, first check whether the port already has a maintainer. Run
%% port info --maintainer $portname where $portname is the name of the port you want to maintain. If the output is
maintainer: the port is unmaintained and you are more than welcome to take it over. If the output lists a different email address, you can still co-maintain the port, but you should contact the existing maintainer(s) first. Once you have verified that a port is unmaintained or the existing maintainer has invited you to co-maintain the port of your choice, follow these steps to become a maintainer: 1. Locate the port's director y and make a copy. MacPorts can help you locate the directory that conta ins the Portfile by running port dir $portname. Copy this directory to a separate location (so you can easily generate a patch later) that is readable by the macports user. In general, your home directory does not fulfill that requirement, but /var/tmp does.
%% cp -r $(port dir $portname) /var/tmp Check /var/tmp for the new directory. In most cases, its name should be equal to the name of the port you want to maintain. In those few cases where it is not (i.e., the so-called subports feature is used), check the output of port dir $portname for the correct name. 2. Change to the new directory and run port info to make sure everything went right. Note that running any port command without a port name tries to use the Portfile in the current directory. This is very helpful when testing modifications or new ports, so keep this in mind.
%% cd /var/tmp/$portname %% port info If you don't see info output for the port, but an error message instead, it will usually be in the following form:
Can't map the URL 'file://.' to a port description file ("couldn't read file "P Please verify that the directory and portfile syntax are correct. To use the current port, you must be in a port's directory. Pay attention to the part in the brackets in the first line. It will either contain a permission problem (in which case you need to adjust the permissions of your Portfile and the folders leading up to it), or a Tcl error message, in case of syntax errors in the Portfile . Also check that the copy of the working directory is in fact the current working directory in your shell. 3. Open the Portfile in your favorite editor and look for the line that starts with maintainer. Delete nomaintainer from the line if it exists and add your own GitHub username or email address. For GitHub usernames, prefix your username with an @ sign. Email addresses should be written in the form domain.tld:localpart. The address is obfuscated to prevent email harvesters from automatically grabbing your address. If you want, you can start fixing bugs in the Portfile as well. At this point, please read Section 7.3.1, “Non-Maintainer Port Updates” and familiarize yourself with the meaning of openmaintainer. Consider adding openmaintainer to speed up and simplify small updates of your port. If you decided to allow minor updates without consultation, add openmaintainer, separated with a space, to the maintainer line of the Portfile. Once you are done, save the file and verify the Portfile structure using MacPorts' builtin lint check:
%% port lint --nitpick You will likely see at least one error:
Error: Portfile parent directory tmp does not match primary category $XYZ You can safely ignore this message. It is printed because the copy of the port's directory is not in a directory named after the port's primary category, but in /var/tmp instead. Please try to address all other warnings and error messages, though. If you need help, feel free to continue and add a note to the ticket you will create asking for instructions. Finally, run port info again. The maintainers line in the output should now contain your email address or GitHub username.
Note https://guide.macports.org/#installing.macports.git
Page 77 of 81
MacPorts Guide
22/09/17 8:30 p.m.
If you made changes other than the maintainer line, you might want to test build and installation as well. To do that, run sudo port destroot in the port's directory. If you see
Error: Unable to execute port: Could not open file: /private/va check the permissions of the Portfile and all folders above it. They must be readable by the macports user. The easiest way to ensure this is to run
%% chmod -R go+rX /var/tmp/$portname If the port fails to build, see the main.log referenced in the error message for details. If the build completes successfully, run sudo port clean to clean up all leftovers.
4. Create a patch from the changes you made to the Portfile and possible related files. To do that, run
%% diff -uR $(port dir $portname) . > change-$portname-maintainer.diff in the directory where you edited the Portfile. You can inspect the generated unified diff in change-$portnamemaintainer.diff if you want. 5. If you are only changing the maintainer, file a new ticket in Trac. Set type to enhancement . Leave the milestone field empty. If you added yourself as co-maintainer, add the other maintainers in the Cc field. Finally, fill in the port field, set keywords to haspatch (because you are attaching a patch), check the box that you want to attach files to the ticket and submit. After submission, attach the patch you created in the previous step. If you are also fixing a bug, attach a separate patch for that change to the same ticket. If you are fixing a bug that already has a ticket, attach a patch fixing the bug there and file the maintainer change in a separate ticket (with a separate patch) as discussed above. In general, please create a separate patch for each semantic change. Doing so simplifies reviewing. It enables each independent change to be accepted without worries about conflicts that sometimes arise when several changes are rolled into one patch. Do not worry that you cannot change the keywords to haspatch on existing tickets. 6. If your ticket doesn't receive any attenti on within a few days you may send an email to and request a review and/or commit. Please include a link to the ticket. Once you are the maintainer for a port, all new tickets for this port will be assigned to you. You are expected to take a look at these tickets, give advice and try to debug problems. If you are stuck, do not hesitate to ask on the list.
7.3. Port Update Policies Port maintainers normally are given commit privileges to the Subversion repository so they can make updates to their own ports as described in Section 7.5, “MacPorts Membership”. However, The MacPorts Project does not restrict commit privileges for maintainers, so before a person other than a port's maintainer updates a port it is a good practice to inform a port's maintainer. See details below.
7.3.1. Non-Maintainer Port Updates If you have a port update or bugfix for a port you do not maintain, to respect the rights of the port maintainer you should follow the following guidelines: 1. If a port's maintainer is , you may feel free to make updates and/or take maintainership of the port. 2. If a port's maintainer contains the address , this means that the author allows minor updates to the port without contacting him first. But permission should still be sought for major changes. 3. Create patch file(s) as necessary, attach them to a Trac ticket, and assign the ticket to the maintainer ( or Cc him or her, if you are unable to assign tickets). 4. Wait for a response from the maintainer. The maintainer should apply the patches and close the ticket within 72 hours. However, for maintained ports without , there are some conditions under which maintainer permission may be waived: If the maintainer does not respond within 72 hours, you or another committer may review the patches and update the port. The log message of this commit must explain that you are taking advantage of maintainer timeout and include a reference to the ticket. If you are not a committer you may send an email to and request the updates be committed. A port is abandoned by its current maintainer. A port against which a Port Abandoned ticket has been filed (see below) can be updated without contacting the maintainer. A critical port is broken that affects many users.
7.3.2. Port Abandonment A port may be considered abandoned if any of the following apply: A bug has not been acknowledged for more than three weeks after a ticket is filed. All tickets filed against the port have been resolved with no input from the maintainer, after the 72-hour timeout, for a significant period of time (at least three weeks). This needs to involve a reasonable number of tickets; one timeout doesn't make a port abandoned.
https://guide.macports.org/#installing.macports.git
Page 78 of 81
MacPorts Guide
22/09/17 8:30 p.m.
The listed maintainer address bounces, and no alternate way of contacting the maintainer is known. If you wish to initiate the Port Abandonment protocol and optionally volunteer as the new maintainer: 1. File a new Trac ticket with the summary line: [Port Abandoned] portname . 2. The ticket should be assigned to the maintainer. Non-macports team members should Cc the maintainer. 3. Set the ticket Type to Defect. 4. In the Description field, refer to any unacknowledged ticket(s). 5. In the Port field, indicate which port is abandoned. 6. The Port Abandoned ticket may be closed when the new maintainer is assigned, and the origi nal ticket(s) with the updates may be resolved as usual. The former maintainer should be removed from all other tickets on which they were assigned as owner. The Port Abandoned ticket should stay open for the usual 72-hour timeout period, to give the maintainer one last chance to indicate that they have not actually abandoned the port.
7.4. Updating Documentation 7.4.1. Updating the Guide The sources for this guide are kept in a Git repository on GitHub. If you spot any error or outdated information, you are encouraged to submit a pull request following the steps outlined below. 7.4.1.1. Preparing Changes
1. First, clone the sources to your computer and switch to a new branch for your changes:
$ git clone https://github.com/macports/macports-guide.git $ cd macports-guide $ git checkout -b my-changes origin/master 2. Make your changes to the file in the guide/xml/ directory that corresponds to the section you want to make changes to.
$ $EDITOR guide/xml/ 3. Verify your changes are still valid XML. First, instal l the required software from MacPort s if you do not already have it installed. If the make validate command reports errors, fix the XML sources until you see no more error messages.
$ sudo port install libxslt docbook-xsl $ make validate 4. Convert the guide to HTML and view the new version in your browser.
$ make guide $ open guide/html/index.html 5. Commit your changes to the local branch and describe your changes in the commit message. See also our wiki page CommitMessages that explains how to write good commit messages.
$ git commit -a 7.4.1.2. Creating a Pull Request
You can submit your changes for inclusion in the guide by making a pull request on GitHub. 1. Visit the macports-guide repository on GitHub and press the Fork button in the upper right corner. This will create a macports-guide repository in your own GitHub account. Add your new repository as a remote to your local repository, rebase your changes on top of the current upstream master and push the result to your new repository on GitHub.
$ git remote add https://github.com//macports-guide.git $ git pull --rebase $ git push my-changes 2. From here on, follow the GitHub documentation on how to create a pull request.
7.5. MacPorts Membership A requirement for a person to become a MacPorts committer is to first become involved and contribute to the project. This may be done by having a record of contribution to the project in several of the following ways: Contributing new ports. Fixing bugs in existing ports. Volunteering as a maintainer of non-maintained ports. Involvement on MacPorts development and/or user support mailing lists. Contributing with documentation. To apply for MacPorts commit rights, send a brief email to the PortMgr team at
https://guide.macports.org/#installing.macports.git
Page 79 of 81
MacPorts Guide
22/09/17 8:30 p.m.
entitled “Commit access: Your Name ” with the following contents: a description of your application and why you think you deserve commit rights. Include evidence of contributions to MacPorts as described above; at best add direct links to Trac tickets or Trac searches that make the review easier for the PortMgr team.
@macports.org the identity you'd like to use as a member of the project, a.k.a. the “handle”, as part of your handle alias. a real e-mail address to which you'd like your MacPorts alias to forward. The PortMgr team will consider all applications and provide an appropriate response as soon as they get to it.
7.6. The PortMgr Team The MacPorts PortMgr team is the steering group for The MacPorts Project. Its membership is usually determined by public elections among project members; the current members of the team can be found on the MacPorts Developers wiki page. They are responsible for matters such as: approving new project members (i.e., granting commit rights); setting general guidelines for the project; dispute resolution; managing the projects infrastructure; and engineering releases.
Chapter 8. MacPorts Guide Terms Glossary MacPorts Guide Terms activate phase automake autoconf API BSD Unix CVS destroot phase port binary build build phase checksum checksum phase compile configure configure phase dependency destroot phase diff extract phase fetch phase free software global keyword gunzip keyword keyword argument modifier keyword list modifier library
https://guide.macports.org/#installing.macports.git
Page 80 of 81