fix(update): stop offering an update that a package-managed install cannot apply

[PathGao]

Closes #570.

What a user sees today

①  .deb install → Settings → "Check for updates…"
②  "Markpad v2.7.3 is available. You're on v2.7.2."     ← the check succeeds
③  Download & Install → fails

Being offered an update that cannot be installed is worse than not being offered one. Roughly 18 people per release can reach this (v2.7.2: .deb 15, .rpm 3), plus snap.

Why both halves behave that way

The check succeeds because latest.json publishes the plain linux-x86_64 key, which every Linux build asks for. That is correct and must stay — build.yml explains why at length, and it is the key the AppImage needs.

The install fails because the updater has exactly one Linux strategy: rename the downloaded file over the running executable.

AppImage   $APPIMAGE — a file the user owns              →  works
.deb       /usr/bin/Markpad                              →  needs root
.rpm       /usr/bin/Markpad                              →  needs root
snap       /snap/markpad/<rev>/…  read-only squashfs     →  impossible

It would normally pick install_deb / install_rpm instead:

// tauri-plugin-updater-2.10.1/src/updater.rs
match installer_for_bundle_type(bundle_type()) {
    Some(Installer::Deb) => self.install_deb(bytes),
    Some(Installer::Rpm) => self.install_rpm(bytes),
    _ => self.install_appimage(bytes),      // ← None lands here
}

bundle_type() reads __TAURI_BUNDLE_TYPE, a static patched into the binary after the build — and that patch fails on Linux. From the v2.7.2 release build, three times, once per bundle:

Warn Failed to add bundler type to the binary: __TAURI_BUNDLE_TYPE variable not
found in binary. … Updater plugin may not be able to update this package.

So bundle_type() is None, all three formats take the AppImage path, and install_deb/install_rpm are unreachable code in our builds.

This symbol is already documented in this repository. build.yml's comment on latest.json explains that Windows and Linux clients cannot ask for an installer-suffixed key precisely because they do not know their own bundle type. That consequence was understood; this one — that it also decides how the update installs — was not followed through.

The change

Ask before checking, not after.

• self_update_supported — one Rust command. On Linux, true only when running from an AppImage; elsewhere always true.
• runCheck() consults it first and enters a new package-managed phase, which tells the user where updates actually come from.

Two details worth stating:

It reads tauri's Env, not std::env::var("APPIMAGE"). Tauri additionally verifies the running executable is under $TMPDIR/.mount_, so exporting the variable by hand cannot make a package-managed install claim it is updatable.

Windows and macOS are untouched. Windows' updater runs the downloaded NSIS installer rather than overwriting in place, and macOS is the one platform where bundle_type() answers without the patch. Gating either would break a working updater for 95% of downloads.

Localisation: four languages, not 26

The update dialog is translated into en, zh-CN, zh-TW and ko only — the other 22 languages already fall back to English for all 24 of its strings. Adding the two new keys everywhere would put two localised lines inside an otherwise English dialog, so they match the existing set exactly. A test asserts the two sets are equal in both directions, so neither a missing translation nor an inconsistent one can land quietly.

(That 22-language gap is real and worth its own issue; it is not this PR's to fix.)

Verification

cargo check	clean (the pre-existing unused import: State warning is on master too — checked, not introduced here)
npm test	965 pass
npm run check	675 files, 0 errors
mutation: move the gate after check()	the ordering test fails, the other four still pass

The ordering test is the important one. Asserting that both calls exist would pass on the broken code, since the broken code also makes both calls — the defect is entirely in their sequence, so that is what is asserted.

What is not verified here, and cannot be: the Linux branch is cfg'd out on macOS, so the ubuntu-22.04 job in this PR is the first thing that type-checks it. And the new phase is unreachable on macOS and Windows by design, so only a real .deb, .rpm or snap install can display it — worth a look on the first release that carries this.

🤖 Generated with Claude Code