Keep existing wine when installing Lutris

[Bartok9]

Summary

omarchy install gaming lutris always omarchy-pkg-adds wine-staging. If wine is already installed, pacman reports an unresolvable conflict (wine-staging vs wine) and the unattended --noconfirm install aborts.

If wine is present and wine-staging is not, keep wine and still install Lutris plus the rest of the stack. Fresh installs still get wine-staging. Replacing wine remains a decision for the person at the machine.

Fixes #11301

Test plan

• bash test/shell.d/lutris-wine-conflict-test.sh
• Reproduce: wine installed, no wine-staging → installer should not request wine-staging.

[johnpippett]

The installer keeps the existing wine package in the automatic checks. New installations still select wine-staging. The checks found no regression in these cases.

Head: 1964c3b34b60a58c1ae7a4dabd82a6e4ebcedf90
Base: 31bd80daa4613ffdee995ac27467fce5a2990806

A test harness did 16 scenarios on each revision. All 32 executions gave the specified results.

Package state	Base result	Head result
wine installed	Package-conflict error; installer stops	Installer selects wine and completes
No Wine package installed	Installer selects wine-staging and completes	Same
wine-staging installed	Installer keeps wine-staging and completes	Same
Complete package set with wine	Package-conflict error	Installer completes without a package transaction

Cases also included package errors, missing packages after a transaction, graphics-package errors, and a shebang-edit error. These errors stopped application launch.

The harness used the installer, package helpers, and graphics-package helper from each source revision. Package-manager and command stubs supplied package states and recorded external operations. The tests did not install packages or start Lutris.

Environment: Linux x86_64, Bash 5.3.15, Python 3.14.7, and bubblewrap 0.11.2. Each test process had an empty home directory and no network or desktop access. Further tests are necessary for actual dependency resolution and graphical operation.

The new test/shell.d/lutris-wine-conflict-test.sh gave the required result, but it only searches source text. Its wine_pkg=wine search also finds wine_pkg=wine-staging. A runtime test with package stubs can show the selected package and error behavior directly.

Codex agents did these tests and prepared this review.

[omarchybot]

Reviewed at 1964c3b34b60a58c1ae7a4dabd82a6e4ebcedf90. The fix works and is the size the problem calls for. I found nothing to change.

Reproduced on a disposable Omarchy VM, with real pacman and the repo wine package installed:

• On quattro (821ae58), and on this head with the installer change reverted, omarchy install gaming lutris aborts with wine-staging-11.17-1 and wine-11.17-1 are in conflict, as in lutris fails to install if wine is already install #11301.
• On this head, it installs lutris, umu-launcher, wine-mono, wine-gecko, winetricks and python-protobuf, keeps wine, pins the Lutris shebang to /bin/python3, and launches Lutris.
• With no wine installed, it still picks wine-staging. A second run is a no-op. pacman -Q wine matches wine-staging through its provides, and the ! pacman -Qq wine-staging half of the condition is what keeps that case on wine-staging.
• ./test/cli passes. The new lutris-wine-conflict-test.sh passes here and fails with the fix reverted. In the full shell suite, ascii-test.sh and branding-about-animation-test.sh fail, and they fail the same way on quattro, so they are not from this change.

One thing outside this pull request: on a machine with no Intel, AMD or NVIDIA GPU (the VM, for instance), omarchy-install-gaming-gpu-lib32 ends in (( ${#PACKAGES[@]} > 0 )) && …, which returns 1 there. That stops the Lutris installer under set -e after the packages are installed. I stubbed it to exercise the rest of the script. It fails the same way on quattro and is not something this pull request needs to fix.

Who checked it: Claude Opus 5.5 alone. The second opinion (Codex) did not run because the bot's review budget for today is spent, so nobody else has checked this. omabot will not mark it verified until that review has run.

Waiting on the maintainer.

[Bartok9]

Thanks for the VM pass — glad the conflict case and the fresh-install wine-staging path both hold, and that the unrelated shell failures match quattro.

Noted the no-GPU omarchy-install-gaming-gpu-lib32 set -e exit; agreed it is out of scope here. Happy to leave this for the maintainer.