On FreeBSD, what is the difference between installing software from the ports tree and installing it with pkg, and when is building from ports actually worth the time?

## One catalogue, two delivery mechanisms FreeBSD keeps third-party software in the **ports tree** — historically fetched to `/usr/ports`, and nowadays obtained from the project's git repository. Each port is a small directory named by category and program, for example `www/nginx`, containing a `Makefile`, a checksum file, a list of files the port installs, and any patches FreeBSD applies on top of the upstream source. The Makefile declares the upstream distribution file, the dependencies, and the build options. Building from a port is a single command inside that directory: ```sh cd /usr/ports/www/nginx make config # curses menu of this port's build options make install clean ``` The framework fetches the tarball, verifies it, applies patches, configures, compiles, installs under `/usr/local` and registers the result — which matters: a port you build is registered in the same package database that `pkg` uses, so `pkg info` sees it and `pkg delete` removes it. **pkg** is the binary side. The FreeBSD project builds the entire ports tree on its own cluster, with each port's *default* options, and publishes the results as signed binary packages. `pkg install nginx` fetches the finished artefact and its dependencies: ```sh pkg install nginx pkg info nginx pkg delete nginx ``` The published repository comes in two flavours: a **quarterly** branch, which is the default and receives only build fixes and security updates for three months at a time, and a **latest** branch that tracks the ports tree continuously. The choice is a configuration file — the shipped default lives in `/etc/pkg/FreeBSD.conf` and is overridden by a file under `/usr/local/etc/pkg/repos/`. Quarterly gives a stable server; latest gives current versions on a workstation. ## When compiling is genuinely worth it 1. **You need a non-default option.** The binary package for a database or a web server is built with whatever the maintainer chose as sensible defaults. If you need a module the default build omits, or want to omit a dependency you refuse to install, the port is the only way to get it. 2. **You need a local patch.** Dropping a patch into the port's `files/` directory makes it part of every rebuild. 3. **Licence-restricted software.** Some ports cannot legally be redistributed as binaries, so no package exists and the port is the only route. 4. **You are the maintainer**, testing a change before it ships. Everything else is better served by `pkg`. Building a browser, a compiler toolchain or a desktop stack from source costs hours of CPU on every machine and every upgrade, and buys you a binary identical to the one you could have downloaded. ## The mixing hazard The common production failure is a hybrid system: mostly binary packages, with two or three ports built by hand with custom options. Those binary packages were linked against dependencies built with *default* options. A hand-built dependency with different options — or simply built at a different point in the ports tree's history — can present a different ABI or a different set of installed files, and the next `pkg upgrade` may want to replace your customised build with the stock one. Symptoms are missing symbols at start-up, or a package silently reverting to defaults after an upgrade. The supported way out is `poudriere`: it builds ports in clean jails and produces a signed binary repository of your own. You define the option set once, build once, and every machine in the fleet does an ordinary `pkg install` against your repository. You get custom builds *and* binary-package speed and consistency, which is why this is the standard answer for anything larger than a single box. ## Everyday hygiene `pkg audit -F` downloads the vulnerability database and lists installed packages with known issues — worth running from a periodic job. `pkg autoremove` drops dependencies nothing needs any more. `pkg check -d` verifies dependency completeness. `pkg lock` pins a package that must not move. None of these care whether the package arrived as a binary or was built from a port, because both register in the same database. ## What the interviewer is checking That you know these are not rival package managers but one catalogue with two delivery paths; that your default is the binary path; that you can state a concrete reason to compile; and, at any level above beginner, that you know the custom-build problem is solved at fleet scale by building your own repository rather than by compiling on each host.