cua-driver update --apply pipes the vendor installer into bash, which installs a second copy under ~/.cua-driver and links it into ~/.local/bin, stepping around pacman and the repository's release gate. Upstream offers no switch for that path, and a /usr/bin wrapper would not cover it either: the MCP configurations the binary generates record the resolved executable. prepare() rewrites the installer URL inside the binary, in place and at equal length, to file:///usr/lib/cua-driver/pm.sh, a stand-in that declines and names pacman. The build asserts the URL appears exactly twice before the rewrite and not at all after it, so an upstream change to the updater stops the build instead of shipping a live self-updater. Verified in a clean archlinux:base container: pacman -Qkk is clean, the CLI and cursor-theme helper still run, and on the nightly channel update --apply prints the notice, exits 1, and creates nothing under ~/.cua-driver/packages or ~/.local/bin.
13 lines
571 B
Bash
13 lines
571 B
Bash
#!/bin/bash
|
|
# Stands in for the vendor installer. cua-driver-bin points the binary's
|
|
# `update --apply` here instead of https://cua.ai/driver/install.sh, which
|
|
# would otherwise install a second copy under ~/.cua-driver and link it into
|
|
# ~/.local/bin, stepping around pacman and the repository's release gate. The
|
|
# exit status is what `cua-driver update --apply` reports.
|
|
{
|
|
echo "cua-driver is installed by pacman (cua-driver-bin), so the vendor installer is disabled."
|
|
echo "Upgrade it with pacman instead:"
|
|
echo " sudo pacman -Syu cua-driver-bin"
|
|
} >&2
|
|
exit 1
|