Why

For native Windows bottle support (pkgxdev/brewkit#346 + #12984), we need a way to actually run the cross-compiled .exe files in brewkit's Linux test sandbox. Otherwise the test step is reduced to a PE-magic-byte check (necessary but not sufficient).

Wine is the standard tool for that — it implements the Windows API on Linux/macOS hosts and can transparently run native Windows binaries. It's exactly what we need for headless CI.

What we'd need

A winehq.org/wine recipe in pantry. Roughly:

distributable:
  url: https://dl.winehq.org/wine/source/X.Y/wine-{{version.raw}}.tar.xz
  strip-components: 1

versions:
  url: https://dl.winehq.org/wine/source/
  match: …

platforms:
  - linux/x86-64
  - linux/aarch64
  - darwin/x86-64    # via Rosetta on Apple Silicon
  - darwin/aarch64   # via Wine on ARM

build:
  dependencies:
    freetype.org: '*'
    gnu.org/gnutls: '*'
    # … wine's transitive deps
  script:
    - ./configure --enable-win64 --prefix={{prefix}} --disable-tests
    - make -j {{hw.concurrency}}
    - make install

provides:
  - bin/wine
  - bin/wine64

(Wine's build is non-trivial — about 30-60 min single-arch, lots of optional deps. We could probably get away with --without-x and friends for headless CI use.)

What it unblocks

Once winehq.org/wine exists:

1. new(llvm.org/mingw-w64): LLVM-based mingw-w64 cross-compiler (Windows-target toolchain) #12984 — llvm.org/mingw-w64 test step upgrades from "verify PE magic" to "actually run hello.exe and assert stdout" (already wired as soft-dep; activates automatically when wine is available).

2. Future Windows recipes can include real runtime tests in their test: block, e.g.:

   test:
     dependencies:
       winehq.org: '*'
     script:
       - wine64 {{prefix}}/bin/foo.exe --version

3. Brewkit's audit step can sanity-check that bundled .exe files actually load (catches things like undefined imports, ABI mismatches, missing DLLs in the bundle — which a static magic-byte check would miss).

Alternatives considered

• GitHub Actions Windows runners: ~10× CPU minutes, slower, requires a separate workflow. Realistic for a final smoke-test but expensive for every PR.
• wine via Docker base image: would work but couples brewkit's CI infrastructure to a specific Docker image. Less reusable.
• box64 / proton / crossover: wrong tool, commercial, or not designed for this use case.

Wine in pantry is the cleanest fit: same model as every other build dep, opt-in per recipe.

Open questions

1. Build from source vs. redistribute upstream binaries — WineHQ publishes per-distro packages (.deb for Ubuntu, .rpm for Fedora) but no generic Linux tarball. Source build is the only arch-agnostic path. Acceptable?
2. wine-stable vs. wine-staging — stable is fine for our use case (CLI testing); staging has more recent fixes. Either works.
3. Optional deps — wine builds with optional support for OpenGL, Vulkan, ALSA, Pulse, X11, SDL, gphoto2, … For headless CI we can disable most. Which is the minimal-viable set?

cc @jhheider @mxcl — context: pkgxdev/brewkit#346 RFC + #12984 toolchain PR.