[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.

[hades200082]

It would be great if this was shipped to apt repositories and as a flatpak on flathub too.

[LouisDeconinck]

Any updates on this? Can we please get Ubuntu support with .deb?

[TonybynMp4]

If anyone cares, i made a mirror that auto publishes .deb & .rpm in x64 & x86 for nightly & releases, with in-app updates.
https://github.com/TonybynMp4/t3code

[hades200082]

I would but there's a trust issue.

Not saying you are doing anything nefarious but a third party hosting binaries could have injected anything into them that we can't see.

I would much prefer if Theo just added this in the official releases.

Failing that, you could post details of how others could do it themselves or something more inspectable

[bigpod98]

They will likel, be added to official releases once merged but i do think a repo is still good to have but thats up to theo or trusted third party to host

[TonybynMp4]

I would but there's a trust issue.

Not saying you are doing anything nefarious but a third party hosting binaries could have injected anything into them that we can't see.

Well i mean, it's all public on github, the patches, commits, actions (i think everyone can see those?), unlike some previous solutions i saw that were literally a random binary on a third party site :) !

I would much prefer if Theo just added this in the official releases.

Don't we all 😆

[bigpod98]

We will see what happens when theo publishes his packages and how he piblishes them ill defenetly be pulling them in automated fashion to add to repo of some kind but ill likely not espose those repos publically

[juliusmarminge]

Resolved by #13575 — Linux releases now ship a self-updating .deb (plus the AppImage). Fedora/.rpm was deferred; open a new discussion if you still want that.