Package Managers for Unix-like Systems

Posted on Edited on In Views:

Outline:

  • APT（Advanced Package Tool)
  • pacman

Package Managers for Unix-like Systems

APT (Advanced Package Tool)

apt is a high-level command-line interface for managing packages on Debian-based systems like Ubuntu. It simplifies tasks such as installing, upgrading, and removing software.

Relationship Between dpkg, apt, and apt-get

  • dpkg is the low-level tool that installs, removes, and manages .deb packages locally. It does not handle dependencies or remote repositories.
  • apt-get is a command-line front-end to dpkg that adds support for dependency resolution and remote repositories.
  • apt is a newer, user-friendly interface introduced to unify and simplify common functions from apt-get, apt-cache, and others. It is suitable for most daily package management tasks.

In summary:

  • apt → wraps and simplifies apt-get + apt-cache
  • apt-get → older, more stable and script-friendly
  • dpkg → base-level tool for handling .deb files directly

Commands

Here is the shortened command summary formatted as tables, grouped by task:

Update & Upgrade

Command Description
sudo apt update Refresh package index
sudo apt upgrade Upgrade installed packages
sudo apt full-upgrade Upgrade with allowed removals
sudo apt-get dist-upgrade Legacy version of full-upgrade

Install

Command Description
sudo apt install <pkg> Install a package
sudo apt-get install <pkg> Script-friendly install
sudo dpkg -i <file>.deb Install a local .deb file
sudo apt install -f Fix dependencies after dpkg install

Remove

Command Description
sudo apt remove <pkg> Remove, keep config files
sudo apt purge <pkg> Remove including config
sudo apt autoremove Remove unused dependencies

Query

Command Description
apt search <term> Search available packages in the local package index, which a locally cached list of packages and metadata downloaded from the configured repositories.
apt show <pkg> Show package details
apt list --installed List installed packages
dpkg -l List all installed packages
dpkg -L <pkg> List files from an installed package

Homebrew (brew)

Homebrew is a package manager for macOS. It installs software into a single prefix (managed directory tree) and exposes executables via symlinks so they are available on your PATH.

This note focuses on the mental model: where things are installed, how they are exposed, and what “sources” mean in Homebrew.

1) Directory layout: Cellar vs opt vs bin

Homebrew installs software under a single prefix (Apple Silicon: typically /opt/homebrew; Intel: /usr/local) and uses symlinks to expose commands on your PATH. It helps to separate three layers:

  1. Cellar — the real installation directory (versioned)

    Each formula is installed into a versioned path:

    1
    $(brew --prefix)/Cellar/<formula>/<version>/

    Example (real binary location):

    1
    /opt/homebrew/Cellar/foo/1.2.3/bin/foo

  2. opt — a stable symlink to the currently active version of a formula

    Homebrew creates a stable symlink:

    1
    $(brew --prefix)/opt/<formula> -> $(brew --prefix)/Cellar/<formula>/<version>/

    Example:

    1
    /opt/homebrew/opt/foo/bin/foo -> /opt/homebrew/Cellar/foo/1.2.3/bin/foo

    Use opt paths in scripts because the path stays constant across upgrades; only the symlink target changes.

  3. bin — user-facing commands on PATH (usually symlinks or wrappers)

    Executables are linked into:

    1
    $(brew --prefix)/bin

    The command you run is typically a symlink chain:

    1
    2
    /opt/homebrew/bin/foo -> /opt/homebrew/opt/foo/bin/foo
                         -> /opt/homebrew/Cellar/foo/1.2.3/bin/foo

    So binaries “appear” in bin because Homebrew links them there; the real files are still in the Cellar.

Useful checks:

1
2
3
4
brew --prefix                 # Homebrew prefix
brew --prefix <formula>       # usually /opt/homebrew/opt/<formula>
ls -l "$(which <cmd>)"        # see if the command is a symlink/wrapper
realpath "$(which <cmd>)"     # resolve the final target (often in Cellar)

2) Package types: formula vs cask

Homebrew supports two major package types because macOS software is distributed in different formats.

Formula

  • Mostly CLI tools, libraries, language runtimes, and daemons.
  • Installed under the Homebrew prefix (Cellar/opt/bin/lib/include/...).
1
brew install <formula>

Cask

  • Mostly macOS GUI apps distributed as .app / .dmg / .zip / .pkg.
  • Installed into /Applications (or ~/Applications).
1
brew install --cask <cask>

3) Tap: package definition repositories

A tap is a repository of package definitions (formulae and/or casks). Conceptually it is similar to adding a package repository.

  • Defaults include homebrew/core (formulae) and homebrew/cask (casks).
  • Add a third-party tap:
1
brew tap <org>/<repo>

List taps:

1
brew tap

4) “Sources” in Homebrew: what can be mirrored

“Changing Homebrew sources” may refer to different layers:

  1. Tap Git remotes Where formula/cask definitions are fetched from (Git repositories).

  2. API domain (metadata) JSON metadata used by modern Homebrew (versions, bottle availability, checksums, etc.).

  3. Bottle domain (prebuilt binaries) Where precompiled bottles are downloaded from. This is often the main speed bottleneck.

  4. Upstream source tarballs Used only when building from source; URLs vary per package.

Inspect your current configuration (especially if you set mirrors):

1
2
brew config
env | grep '^HOMEBREW_' | sort

5) Common commands

Search and inspect:

1
2
brew search <keyword>
brew info <name>

List installed files for a formula:

1
brew list <formula>

Get the stable formula prefix (usually the opt path):

1
brew --prefix <formula>

6) Switching versions (when versioned formulae exist)

If Homebrew provides versioned formulae (e.g., [email protected]), you can control which version is linked into $(brew --prefix)/bin:

1
2
brew unlink go
brew link --overwrite [email protected]

7) Installation and mirrors (China mainland)

Homebrew installation is covered in the official documentation, so I omit it here. In mainland China, using a mirror can significantly improve reliability and download speed.

Tsinghua TUNA provides a widely used guide covering installation and mirror configuration:

  • Homebrew 软件仓库（TUNA）

For an additional walkthrough (blog post):

  • 如何加速 Homebrew 在 macOS 上的下载速度

Mirror configuration via environment variables (USTC example)

The following environment variables redirect different Homebrew “sources” to USTC mirrors. Add them to your shell profile (e.g., ~/.zshrc or ~/.zprofile) so they apply to every new terminal session.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Speed up Git fetches for the Homebrew software itself (Homebrew/brew)
export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.ustc.edu.cn/brew.git"

# Speed up Git fetches for the Core tap (homebrew/core), which contains most formula definitions
export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.ustc.edu.cn/homebrew-core.git"

# Speed up bottle downloads (prebuilt binaries). This is often the biggest performance win.
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles"

# Speed up Homebrew’s JSON API (metadata for versions/bottles/checksums)
export HOMEBREW_API_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles/api"

# Suppress Homebrew warnings/hints about custom HOMEBREW_* environment variables
export HOMEBREW_NO_ENV_HINTS="1"

Verification:

1
2
3
4
5
6
brew config
env | grep '^HOMEBREW_' | sort

git -C "$(brew --repo)" remote -v
# If core is present locally:
git -C "$(brew --repo homebrew/core)" remote -v 2>/dev/null