[architect] GNOME OS installer prototype vendored into files/ without upstream pin — org.gnome.Installer D-Bus service ships in KDE live image

[hanthor-hive-agent]

Architecture Finding

Type: coupling / vendored third-party
Affected area: files/kde-linux-system/live/proto-installer/ (+ live/Cargo.toml, elements/kde-linux-system/live.bst)

The live image builds a full installer stack from a vendored snapshot of the GNOME OS installer prototype:

• proto-installer/installer.py (317 LOC, Python GTK4 + dbus/UDisks)
• proto-installer/daemon/main.rs (747 LOC Rust daemon: logind.rs, polkit.rs, systemd.rs, zbus)
• Ships the org.gnome.Installer D-Bus service name, gnomeos-installer install prefix, and org.gnome.Installer.desktop in the KDE live image.

There is no provenance/pin anywhere: no README, no upstream commit/tag reference, no submodule, no sync workflow. It is wired into the build through elements/kde-linux-system/live.bst → live/meson.build (subdir('proto-installer') + cargo custom target).

Impact

• This is the org's Nth installer implementation (ties into [architect] Installer backend logic reimplemented 5× in 5 languages — offline probe, privilege escalation, product name, encryption table, readiness tunaOS#1197: installer backend logic reimplemented 5×) — a vendored upstream prototype that cannot receive upstream fixes (security, partitioning, TPM/verity handling) without manual re-vendoring.
• The org.gnome.Installer service name is a branding/provenance mismatch inside a TunaOS KDE image: future tuna-os installer work (bootc-installer family) may conflict or double-register D-Bus services.
• An unpinned vendored tree is a drift trap: no way to answer "what did we change from upstream, and when does upstream supersede us?" — the exact failure mode seen with tuna_installer/ in fisherman ([architect] tuna_installer/ is a broken, half-renamed fork of upstream bootc-installer — orphaned dead code fisherman#104).

Recommendation

• Record the upstream baseline: document the source project + pinned commit (README in the dir or a metadata file), or convert to a submodule with an explicit revision.
• Decide intent: either adopt/upstream the installer officially (branding + pin + sync workflow), or delete the prototype and standardize on the bootc-installer family per [architect] Installer backend logic reimplemented 5× in 5 languages — offline probe, privilege escalation, product name, encryption table, readiness tunaOS#1197.
• Rename the D-Bus service/prefix (e.g. org.tunaos.Installer) if it stays, so the KDE live image doesn't ship a GNOME-branded service.

---

Filed by architect agent (ACMM L6 — full mode)

🐝 Hive Agent: architect | Instance: hive-keen-mink | SHA: unknown