If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Linuxbrew/brew shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 7y ago

• 7 active contributors
• BSD-2-Clause licensed
• Tests present
• ⚠ Stale — last commit 7y ago
• ⚠ Concentrated ownership — top contributor handles 62% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Linuxbrew/brew repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Linuxbrew/brew.

What it runs against: a local clone of Linuxbrew/brew — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Linuxbrew/brew | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-2-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2665 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Linuxbrew/brew. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Linuxbrew/brew.git
#   cd brew
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Linuxbrew/brew and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Linuxbrew/brew(\\.git)?\\b" \\
  && ok "origin remote is Linuxbrew/brew" \\
  || miss "origin remote is not Linuxbrew/brew (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-2-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-2-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-2-Clause" \\
  || miss "license drift — was BSD-2-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Library/Homebrew/brew.rb" \\
  && ok "Library/Homebrew/brew.rb" \\
  || miss "missing critical file: Library/Homebrew/brew.rb"
test -f "Library/Homebrew/cask/cask.rb" \\
  && ok "Library/Homebrew/cask/cask.rb" \\
  || miss "missing critical file: Library/Homebrew/cask/cask.rb"
test -f "Library/Homebrew/cask/installer.rb" \\
  && ok "Library/Homebrew/cask/installer.rb" \\
  || miss "missing critical file: Library/Homebrew/cask/installer.rb"
test -f "Library/Homebrew/cask/cmd.rb" \\
  && ok "Library/Homebrew/cask/cmd.rb" \\
  || miss "missing critical file: Library/Homebrew/cask/cmd.rb"
test -f "Library/Homebrew/build.rb" \\
  && ok "Library/Homebrew/build.rb" \\
  || miss "missing critical file: Library/Homebrew/build.rb"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2665 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2635d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Linuxbrew/brew"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Linuxbrew/brew is the Linux fork of Homebrew, a package manager that installs software into a user's home directory (~/.linuxbrew or /home/linuxbrew/.linuxbrew) without requiring sudo. It brings macOS Homebrew's formula-based dependency resolution and bottle (binary) caching to Linux and Windows WSL, solving the problem of managing up-to-date software on systems where the native package manager is outdated or lacks certain packages. Monolith structure: Library/Homebrew/ contains the core engine (brew.rb entry point, build.rb orchestration); Library/Homebrew/cask/ handles artifact installation (apps, binaries, fonts via abstract_artifact.rb and concrete implementations); .circleci/config.yml drives CI; Dockerfile and Dockerfile.test.yml define container build steps; .rubocop*.yml files enforce code style across multiple contexts (shared, rspec, cask, audit).

Linux and WSL users who want to install and manage development tools, languages, and libraries without system-wide package manager friction or sudo privileges; DevOps engineers and developers who need consistent package management across macOS, Linux, and Windows systems.

This repository is now archived and no longer maintained (merged into Homebrew/brew as of 2019). While the codebase is production-quality with comprehensive CI via CircleCI, RuboCop linting, and extensive Roff documentation, active development has ceased. Users should migrate to the main Homebrew project.

The critical risk is that this repo receives no updates—security patches, bug fixes, and new formulas only flow to Homebrew/brew. The Ruby codebase is large (2.1M lines) with complex dependency graphs (build.rb, build_environment.rb, cask/ subsystem), making local modifications high-friction. Windows/WSL-specific paths through the code may have latent bugs since active testing moved upstream.

This repository is in maintenance-only mode post-merger into Homebrew/brew (February 2019). No active feature work or commits are occurring here; all development has moved to Homebrew/brew where Linux support is now a first-class concern rather than a fork.

git clone https://github.com/Linuxbrew/brew.git
cd brew
./bin/brew --version
./bin/brew help

Note: This is a read-only archive. For active development, use https://github.com/Homebrew/brew instead.

Daily commands:

./bin/brew install <formula>    # Install a package
./bin/brew update             # Update formulae
./bin/brew list               # List installed packages
./bin/brew cask install <cask> # Install graphical apps (via cask subsystem)

For development: ruby -I Library/Homebrew Library/Homebrew/brew.rb [args]

• Library/Homebrew/brew.rb — Main entry point for Homebrew CLI; all commands route through this file.
• Library/Homebrew/cask/cask.rb — Core abstraction for cask package definitions; defines installation lifecycle and artifact handling.
• Library/Homebrew/cask/installer.rb — Orchestrates cask installation, download, and artifact placement; critical for package deployment.
• Library/Homebrew/cask/cmd.rb — Command dispatcher for all cask subcommands (install, uninstall, upgrade); entry point for user actions.
• Library/Homebrew/build.rb — Handles formula build configuration and environment setup; central to compilation pipeline.
• Library/Homebrew/build_environment.rb — Configures build toolchain and system dependencies; ensures reproducible builds across environments.
• Library/Homebrew/cache_store.rb — Manages local caching of downloads and build artifacts; improves performance and offline capability.

Add a new Cask artifact type

1. Create a new artifact class in Library/Homebrew/cask/artifact/ inheriting from AbstractArtifact (Library/Homebrew/cask/artifact/abstract_artifact.rb)
2. Implement install() and uninstall() lifecycle methods specific to your artifact type (Library/Homebrew/cask/artifact/app.rb)
3. Register the new artifact type in the artifact factory (Library/Homebrew/cask/artifact/artifact.rb)
4. Add audit rules for your artifact type in the auditor (Library/Homebrew/cask/auditor.rb)
5. Test installation, uninstall, and upgrade flows for your artifact type

Add a new cask command (e.g., brew cask mycommand)

1. Create a new command class in Library/Homebrew/cask/cmd/ inheriting from AbstractCommand (Library/Homebrew/cask/cmd/abstract_command.rb)
2. Implement run(args) method with your command logic (Library/Homebrew/cask/cmd/install.rb)
3. Register the command in the dispatcher (Library/Homebrew/cask/cmd.rb)
4. Add help text and option documentation in your command class

Add a new cask DSL stanza (e.g., my_metadata field)

1. Create a new DSL class in Library/Homebrew/cask/dsl/ inheriting from Base (Library/Homebrew/cask/dsl/base.rb)
2. Define the stanza name and validation logic (Library/Homebrew/cask/dsl/depends_on.rb)
3. Register the stanza in the Cask class (Library/Homebrew/cask/cask.rb)
4. Add audit rules to validate stanza correctness (Library/Homebrew/cask/audit.rb)

Add a new build option or environment variable

1. Define the option in the build configuration system (Library/Homebrew/build_options.rb)
2. Apply the option in the build environment setup (Library/Homebrew/build_environment.rb)
3. Update build.rb to pass the option through the compilation pipeline (Library/Homebrew/build.rb)

• Ruby — Dynamic language enables rapid iteration on package definitions; DSL metaprogramming allows expressive cask syntax without compilation.
• Shell/Bash integration — Direct system command execution for artifact placement, permissions, and platform-specific operations (e.g., launchctl on macOS).
• File-based caching — Simple, portable cache without external dependencies; survives restarts and is user-inspectable.

• Separate cask (binary packages) from formula (source packages) implementations

  • Why: Casks target pre-built applications with artifact handling; formulas target source compilation. Different lifecycle and verification models.
  • Consequence: Code duplication in command dispatch and validation; maintainers must keep both paths in sync.

• Post-download artifact placement (extract, symlink) instead of container-based isolation

  • Why: Direct filesystem integration maximizes compatibility with existing POSIX tooling and GUI application frameworks.
  • Consequence: Uninstall must cleanly reverse all placements; no sandboxing or rollback guarantees if installation partially fails.

• Local file-based cask definitions instead of server-side registry

  • Why: Decentralized, offline-capable; users can fork and customize; transparent DSL in plain Ruby.
  • Consequence: No centralized version conflict resolution; users must manage formula/cask repo updates manually.

• Real-time package update notifications or streaming downloads
• Dependency resolution across multiple package formats (RPM, Deb, etc.)
• GUI application installer (headless CLI only)
• Windows native support (WSL only)

This repo is archived—PRs and issues are not being reviewed. The build system assumes a Linux environment with glibc and gcc (or Linuxbrew's own bootstrapped versions); macOS builds will fail. PATH setup via brew.sh is critical and environment-specific (different between ~/.linuxbrew and /home/linuxbrew/.linuxbrew). The cask subsystem has complex artifact installation logic with platform-specific uninstall hooks (see abstract_uninstall.rb); modifying these risks breaking existing installations. RuboCop has separate rule sets (.rubocop_cask.yml, .rubocop_rspec.yml, .rubocop_audit.yml) that must be considered together; ignoring any one will cause CI failures.

• Formula — The core abstraction in Homebrew—each formula defines how to download, patch, configure, compile, and install a package; understanding the formula structure is essential to extending Linuxbrew with new packages
• Bottle (Binary Package) — Pre-compiled binaries cached by Linuxbrew to avoid recompilation; critical to understanding why Linuxbrew can work without a full toolchain and how platform detection affects bottle availability
• Tap (Third-party Repository) — External formula repositories that extend Linuxbrew beyond the core; understanding how taps are resolved and loaded is necessary for debugging package lookup and version conflicts
• Cellar — The directory structure where Linuxbrew installs versioned packages (e.g., ~/.linuxbrew/Cellar/python/3.9.0); critical to understanding how Linuxbrew avoids conflicts and enables multiple versions
• Cask (Graphical Application Artifacts) — The artifact system (Library/Homebrew/cask/) handles non-formula installations like apps, fonts, and dictionaries; understanding cask artifacts is essential for extending Linuxbrew to manage graphical tools
• Build Environment Isolation — Linuxbrew constructs sandboxed build environments (via build_environment.rb) to ensure reproducible compilation across different Linux distributions; this isolation is why Linuxbrew doesn't depend on system libraries except glibc and gcc
• Keg-only Formulae — Some packages are installed to versioned subdirectories without symlinking to PATH; understanding when and why formulae are keg-only prevents PATH conflicts and clarifies why some tools require explicit linking

• Homebrew/brew — The authoritative upstream repository where Linuxbrew was merged; all active development and bug fixes now occur here, making it the canonical resource for Homebrew on Linux
• Linuxbrew/homebrew-core — The formula repository used by Linuxbrew; contains package definitions that brew.rb installs, though it too has been subsumed into Homebrew's core tap
• Homebrew/homebrew-core — The unified formula repository post-merger; the primary source of packages for both macOS and Linux Homebrew installations
• aptly-dev/aptly — Alternative Debian-focused package manager; relevant for understanding how Linuxbrew differs in approach (home-directory vs system-wide, binary bottles vs source compilation)
• spack/spack — Scientific package manager for HPC with similar dependency resolution and multi-platform support; useful reference for how complex build environments are managed in a monorepo context

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for Cask artifact types

The Library/Homebrew/cask/artifact directory contains 25+ artifact type classes (app.rb, pkg.rb, binary.rb, etc.) but there's no visible corresponding test file structure in the provided file listing. Each artifact type handles different installation/uninstallation logic that needs thorough testing to prevent regressions.

• [ ] Create Library/Homebrew/test/cask/artifact/ directory structure mirroring artifact types
• [ ] Add unit tests for each artifact class in Library/Homebrew/cask/artifact/ (app.rb, pkg.rb, binary.rb, etc.)
• [ ] Test install, uninstall, and edge cases for abstract base classes (abstract_artifact.rb, abstract_uninstall.rb)
• [ ] Update .circleci/config.yml to run cask artifact tests in CI pipeline if not already present

Add RuboCop configuration documentation and linting audit automation

The repo has multiple .rubocop.yml files (.rubocop.yml, .rubocop_audit.yml, .rubocop_cask.yml, .rubocop_rspec.yml, .rubocop_shared.yml) scattered across Library/ but no documentation explaining which file applies to which code paths. This creates confusion for contributors on style enforcement.

• [ ] Create Library/Homebrew/RUBOCOP_GUIDE.md documenting each .rubocop* file's purpose and scope
• [ ] Document which config files are inherited/extended and the precedence order
• [ ] Add a GitHub Action workflow in .github/workflows/ to run all four rubocop variants on PR (if not present)
• [ ] Add pre-commit hook documentation to CONTRIBUTING.md for local linting validation

Create integration tests for cask lifecycle operations (install/uninstall)

The cask system has complex artifact handling (Library/Homebrew/cask/artifact/, cask.rb, caskroom.rb, cache.rb, etc.) but there's no visible test coverage for end-to-end cask operations. This is critical for a package manager where install/uninstall failures directly impact users.

• [ ] Create Library/Homebrew/test/cask/integration/ directory for lifecycle tests
• [ ] Add tests in Library/Homebrew/test/cask/integration/cask_install_test.rb for real cask installation flows
• [ ] Add tests in Library/Homebrew/test/cask/integration/cask_uninstall_test.rb covering uninstall and zap operations
• [ ] Ensure tests use mock artifacts and don't perform actual system operations
• [ ] Update .circleci/config.yml to include integration tests in the test matrix

• Add comprehensive documentation to Library/Homebrew/build_environment.rb explaining each Linux-specific compiler flag and when it applies; currently sparse inline comments make onboarding difficult for contributors unfamiliar with cross-platform C/C++ compilation.
• Write integration tests in Library/Homebrew/cask/artifact/ for the uninstall path (abstract_uninstall.rb and its subclasses); currently test coverage appears to focus on install, leaving uninstall logic vulnerable to regressions on package removal.
• Create a troubleshooting guide in the README documenting common PATH issues when Linuxbrew is installed in different locations (~/.linuxbrew vs /home/linuxbrew/.linuxbrew) and how the brew.sh initialization script resolves them; users often report confusion here.

The codebase shows moderate security concerns, primarily stemming from the Dockerfile configuration. Critical issues include unrestricted sudo access for the linuxbrew user and use of an outdated Ubuntu base image (xenial). The incomplete git configuration suggests potential deployment issues. The architecture lacks proper privilege separation and uses security-risky configurations. The Ruby codebase itself (Library structure) appears to follow standard package manager patterns without obvious injection vulnerabilities in the file structure, but detailed code review would be needed. Immediate remediation should focus on removing unrestricted sudo access, upgrading the base image, and implementing proper privilege separation.

• High · Unrestricted sudo Access in Dockerfile — Dockerfile, line: echo 'linuxbrew ALL=(ALL) NOPASSWD:ALL' >>/etc/sudoers. The Dockerfile grants the 'linuxbrew' user unrestricted sudo access without a password (NOPASSWD:ALL). This allows any process running as linuxbrew to execute arbitrary commands with root privileges, significantly expanding the attack surface. Fix: Remove or restrict sudo privileges. If sudo is required, use specific command allowlists instead of unrestricted access. Consider using capability-based access control or running with minimal required privileges.
• High · Incomplete Git Remote Configuration — Dockerfile, final RUN command. The Dockerfile contains an incomplete git remote set-url command that appears to be truncated ('https://github.com/Linuxbr'). This could indicate a build configuration issue or incomplete deployment setup. Fix: Complete the git remote URL configuration and ensure all build commands are properly tested before deployment. Verify the build succeeds end-to-end.
• Medium · Outdated Base Image — Dockerfile, line: FROM ubuntu:xenial. The Dockerfile uses 'ubuntu:xenial' which reached end-of-standard support in April 2021 and is no longer receiving security updates. Running with an unsupported base image exposes the container to known vulnerabilities. Fix: Upgrade to a currently supported Ubuntu LTS release (e.g., ubuntu:22.04 or ubuntu:20.04). Review and test all dependencies for compatibility with the newer image.
• Medium · Missing Security Headers and Hardening — Dockerfile, overall structure. The Dockerfile lacks several security best practices including: no USER directive to drop root privileges after setup, no HEALTHCHECK directive, and missing security-focused APT flags in some commands. Fix: Add 'USER linuxbrew' at the end of Dockerfile to ensure the container runs as non-root. Include security flags like '--no-install-recommends' (already present but could be extended), and consider adding HEALTHCHECK for production deployments.
• Medium · Permissive File Ownership Configuration — Dockerfile, chown command in RUN directive. The command 'chown -R linuxbrew: /home/linuxbrew/.linuxbrew' grants full ownership to the linuxbrew user of the entire installation directory, combined with unrestricted sudo access, creating a privilege escalation risk. Fix: Implement stricter file permissions. Limit write access to specific directories. Combine with removal of unrestricted sudo access.
• Low · Deprecated PPA Usage Without Verification — Dockerfile, add-apt-repository command. The Dockerfile adds PPA 'ppa:git-core/ppa' without signature verification or pinning. While commonly done, this introduces a supply chain risk if the PPA is compromised. Fix: Consider using official Ubuntu repositories instead. If PPAs are necessary, implement additional verification mechanisms or use signed package verification.
• Low · Missing Security Scanning Configuration — .circleci/config.yml. No evidence of container security scanning, vulnerability scanning, or SAST tooling in CircleCI configuration (.circleci/config.yml not shown in detail). The build pipeline should include security checks. Fix: Integrate security scanning tools in the CI/CD pipeline such as Trivy, Snyk, or Hadolint for container image analysis and dependency vulnerability scanning.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.