I wonder if UE can be released as binary tarballs so that Linux developers can save time compiling and spend that time doing something more productive. This has been asked for many times, so sorry for the duplicate. I will explain a bit more regarding my feedback.
I don’t think Epic should release them as .deb or .rpm archives, as it would be too much work maintaining the packages. The package maintaining should be left to the distros’ package maintainers.
I understand if Epic cannot create binary releases. The most obvious reason is because of the lack of people to maintain said tarballs, or UE for Linux is somehow not “ready” yet. For that matter, I will leave it to you.
Threads related to this topic (but talking about .deb instead of tarballs):
For libraries where specific versions are needed, statically-linked could be useful, whereas for libs that [typically] just need to be “version ____ or later” dynamic link to minimize package size. This might also help teams keep their UE editor build in sync despite minor Linux upgrades or “Carol uses Debian while Ahmed prefers Ubuntu, but Geraldo insists on RHEL because of his non-UE projects.”
Even if a single .deb or .rpm (or Flatpak) is not technically feasible, it would be of immense help if Epic provided precompiled binary “sets” where (using Debian and friends as an example) there might be unreal-engine-core-5_0_1-${arch}.deb, unreal-engine-dev-…, and several mix-and-match support packages to support different graphics stacks, GPU drivers, headless server, debug symbols, or whatever. “Everyone needs A, B, and C, then choose either D for headless or one of E, F, or G for GUI” is still easier for non-experts than “here is a complex build chain wrapped around massive source code…”.
My TL;DR point is that it would be okay, IMO, for Epic to distinguish between dead-simple handholding without need for RFTM, versus streamlined and timesaving process easily and reliably repeatable after RTFMing and then doing it a time or two. Most Linux users don’t expect the former but deeply appreciate the latter – especially if assisting other colleagues who may not be Linux sysadmins or coders.