Package LG Buddy as .deb and .rpm

[Staphylococcus]

Problem statement

LG Buddy is currently distributed as a release tarball with shell install/uninstall scripts. That works for early beta testing, but it is not the right end-user experience for mainstream mutable Linux distributions.

We should provide native .deb and .rpm packages that install the runtime, system/user integration files, desktop entry, and documentation in a predictable package-managed way.

This issue intentionally covers .deb and .rpm only. Flatpak is out of scope for this issue.

Dependencies

Blocked by:

• Replace Python TV bridge with native webOS client #20: replace the Python bscpylgtvcommand bridge with a native webOS client
• Add first-party GUI frontend and retire Zenity brightness dialog #22: add a first-party GUI frontend and remove zenity as the brightness UI dependency

Packaging before those are complete would bake fragile runtime assumptions into package metadata:

• Python venv/pip-installed TV control does not belong in a clean system package install path.
• zenity should not be a hard package dependency for core automation.
• The packaged experience should not require terminal commands or config-file editing for normal setup and use.

Target package responsibilities

The packages should install:

• the lg-buddy runtime binary
• systemd system units
• systemd user unit template or installed user-service assets as appropriate
• NetworkManager dispatcher hook
• tmpfiles config
• desktop entry for the first-party GUI frontend
• documentation and license files

The packages should not install:

• a Python virtual environment
• bscpylgtvcommand
• zenity as a hard runtime dependency
• Flatpak-specific integration

Layout questions to resolve

For mutable .deb/.rpm packages, the likely layout is conventional system packaging:

/usr/bin/lg-buddy
/usr/lib/lg-buddy/ or /usr/share/lg-buddy/ package assets as needed
/usr/share/applications/*.desktop
/usr/share/doc/lg-buddy/
/etc/systemd/system/ or packaged unit install locations
/etc/NetworkManager/dispatcher.d/pre-down.d/
/etc/tmpfiles.d/ or packaged tmpfiles location

We should decide whether package-managed units should live under package-owned system locations and use presets/postinstall scripts, or whether the current /etc/systemd/system install-script model needs to be translated into package manager conventions.

Installer/script implications

Once packages exist, install.sh should remain useful for release tarballs and development, but package-managed installs should not rely on ad hoc script behavior.

Packaging work should clarify:

• which setup steps belong in package install scripts
• which setup steps belong in first-run GUI flow
• which steps must remain explicit user actions
• how uninstall/package removal handles user config and runtime state
• how upgrades migrate old script-installed files

Testing scope

Add package build and smoke validation for both formats:

• package builds in CI or a dedicated release workflow
• install package into a clean test root/container where practical
• verify files land in expected package-managed locations
• verify systemd units reference the packaged binary path
• verify NetworkManager hook references the packaged binary path
• verify no Python venv or bscpylgtvcommand is installed
• verify zenity is not a hard dependency
• verify package removal leaves user config alone unless explicitly purged

Release implications

After this lands, releases should publish .deb and .rpm assets alongside or instead of the current tarball, depending on how much compatibility we want to preserve for early users.

---

Migrated from #28 before repository ownership transfer.
Original issue: #28
Original author: @Staphylococcus
Original created: 2026-04-30T17:47:47Z
Original comments at migration time: none.