[Feature]: additional linux packaging

[bigpod98]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

packages/contracts or packages/shared

Problem or use case

installing on anything that isnt archlinux is hassle. It would be great if there existed additional method specially for most popular distributions like fedora and ubuntu and others.

Proposed solution

additional packaging methods could do great specially things like deb packages and fedora packages.

Why this matters

users who want to automatically provision t3code on their servers, those who are resistant to

Smallest useful scope

an ubuntu package

Alternatives considered

i currently have my own build of it but due to it hooking up into existing packaging primatives i am having hard time keeping fork up to date thats what makes me hoping i can get a package from upstream

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[stanleykinkelaar]

Would like this too! a .deb or something would help me out a lot. I'm subscribing to this issue.

[benthecarman]

I made this previously. Would be great. I don't know how any serious developer can use this without a linux package?

#4900

[bigpod98]

@benthecarman

Yea same, why systems depend on everything ening a package and if you want to be smart running NPX(whether it remote "server") just isnt a thing i wanna do on a machine if i dont have to which is why packages. Or on desktop while appimages are fineish they are just clunky to maintain compared to a deb file even of you reinstall for updates

[chukfinley]

Status for anyone subscribed here, since the work is spread over four PRs:

• feat(release): publish Linux .deb and .rpm alongside the AppImage #4071 — release pipeline: one Linux electron-builder run emits AppImage,deb, *.deb added to the collect step and both release upload lists, plus docs, download-page card and tests. Rebased onto current main today, MERGEABLE, checks green.
• feat(packaging): add deb and rpm desktop targets #5139 — deb and rpm targets, runtime depends lists, headless t3 entrypoint. No workflow changes by design.
• feat(desktop): Add a Linux .deb to releases #4900, feat(release): publish a Linux .deb alongside the AppImage #4887 — earlier takes on the same thing.

The consolidation discussion is in #5139: the aim is to get down to one PR so a maintainer has one thing to review instead of four. I've folded the dependency lists and the rpm target from #5139 and the docs/download-page bits from #4900 into #4071 with credit, and said there that I'm happy for any of the four to be the base — no ownership contest, just one PR.

Ubuntu-side result for the "smallest useful scope" in the issue: T3-Code-<version>-amd64.deb, installs with sudo apt install ./T3-Code-*-amd64.deb, app at /opt/T3 Code*/t3code with a .desktop entry. Note in-app updates on Linux stay AppImage-only, so a .deb install upgrades through dpkg/apt.