Proposal: Linux x64 desktop packages (.deb + AppImage) — implementation available (fork branch)

[kgpche]

Summary

The download page ships Desktop installers for macOS and Windows only. We implemented unsigned Linux x64 packages (.deb + AppImage) for the Electron desktop app on a fork, through the existing package-target pipeline, and validated them on real Ubuntu hardware. The full change is available here if the team wants to adopt any of it:

Branch: https://github.com/kgpche/deepseek-harness/tree/linux-desktop-package-target (commit 5688f6c32d, 44 files: pipeline, runtime selection, docs, tests)

One command on a Linux x64 host produces deepseek-harness-<version>-linux-amd64-unsigned.deb plus an AppImage, with the complete built-in smoke chain passing (payload, Host boot, DOCX/XLSX/PPTX→PDF conversion).

What it does

• Registers linux-x64 in the target registry, parsing, host gating, stage naming (linux-package), and output line. The target is deliberately unsigned-only: parsing, environment validation, and config resolution each reject a signed invocation loudly, because no signing or update feed exists for it.
• Routes unsigned macOS and Linux runs through shared local defaults, and stops requiring mandatory-update policy settings for any unsigned build (unsigned builds are local artifacts and embed no policy).
• electron-builder config: deb + AppImage targets, a standard-size icon set (see below), explicit executableName, deb maintainer.
• pnpm run package:desktop:linux:x64:unsigned from the repository root.

Two Linux-specific findings worth knowing about

1. sharp crashes under Electron-as-Node on Linux (electron#46323). The desktop app reuses the installed Electron executable as its Node runtime. On Linux, that executable loads its GTK-linked libraries even under ELECTRON_RUN_AS_NODE=1, and the leaked system glib symbols satisfy the glib references inside sharp's bundled libvips. Image decode then segfaults: gdb shows g_object_unref from the system libgobject-2.0.so.0 called by sharp-linux-x64.node. This is the conflict tracked at electron/electron#46323 (sharp documents it with no workaround; LD_PRELOAD of glib does not fix it).

Our fix: Linux runs the bundled dsh tree under the standalone Node from resources/runtime/primary-runtime (already shipped for plugin execution, pinned to the same Node version Electron embeds — the payload smoke asserts the equality). macOS and Windows keep the Electron runtime unchanged.

2. The standalone Node cannot read inside an ASAR archive, so the Linux package ships the dsh tree as physical files under resources/dsh (electron-builder extraResources) instead of application archive members; the main process, packaged smoke, and the cli/dsh launcher read the physical tree. macOS and Windows keep the ASAR layout.

(Minor third: a single large icon PNG lands in a hicolor directory like 1104x1104/ that index.theme does not declare, so GNOME ignores it and falls back to a generic gear. We ship a standard 16–512 size set instead.)

Verification

• Full packaging run on Ubuntu x64 → deb (274MB) + AppImage; installed with apt install, verified with dpkg-deb; app launches, Host boots, model listing loads, desktop entry and icons appear correctly.
• Runtime payload smoke passes under the standalone Node: sharp, koffi, node-pty, pnpm, ripgrep, plus Host boot and Office (WASM engine) conversions.
• Added/updated tests around the target, environment validation, config resolution (including the fail-loud signed-Linux path), CLI launcher, and runtime preparation; repo-wide aggregate typecheck green.
• Packaging README updated bilingually with the target and its known limitations, plus an agent note recording the standalone-Node decision.

Known limitations (documented in the fork)

Unsigned-only: no auto-update feed, no signing/notarization, not wired into the official download site. The dsh:// deep link registers but its open-url handling is macOS-only, account platform headers label Linux as darwin, and there is no tray (Windows-only upstream as well).

If the team is interested

PRs are currently disabled on this repository, so I'm posting here first. Happy to split or reshape the change however is useful — e.g. pipeline target as one PR, the standalone-Node runtime decision (which has opinions worth reviewing on its own) as another — or to hand over any part of the analysis. The fork branch is maintained and can be rebased.