Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

.deb and .rpm aren't supported by itch, please ship portable Linux builds Sticky

A topic by Amos created Jan 15, 2016 Views: 4,552 Replies: 14
Viewing posts 1 to 7

DEB & RPM policy

Some games on ship with a .deb or .rpm package file.

However, itch (the desktop app), does not support DEB or RPM and will never support them.

Players: if a game you like is distributed using .deb or .rpm, and your Linux distribution supports that format, you always have the option to download it directly from and install it manually.

Developers: follow the guide to get your app running with itch.


Why not just have itch do `sudo apt-get install somegame.deb`?
In descending order of seriousness:

  • It would be a security concern.
    • APT and YUM packages have post-install scripts that are run as root & can harm your system.
    • Proper package repositories are usually signed by people you trust (maintainers of your distribution, the team, etc.)
    • (Signing random packages wouldn't solve anything — it would just make our signature worthless)
  • It would be distribution-specific
    • We're trying to keep itch as distribution-agnostic as possible: it runs great on vanilla Debian, Ubuntu, Fedora, ArchLinux, etc.
  • It would break several itch features
    • Installing packages system-wide would occupy disk space outside of the designated Install locations
    • As a side-effect, we couldn't compute the space taken by an install location, or even find which execs to launch
    • (Sure, we can get dpkg to list installed files & work from that — which is another codepath to maintain, another tool's output to parse, with potentially several versions to support, etc., increasing the app's complexity and potential for bugs)

Why do you distribute .deb and .rpm packages of itch then?
Because itch:

  • Is a piece of utility software
  • ...that needs an easy way to stay up-to-date for end-users
  • ...that registers a protocol scheme handler (`itchio://`), creates a desktop shortcut, etc.

Doing this is a lot of work, but if you choose to distribute your own software, you should definitely have it do all these things — shortcut creation, have a repository (with packages signed by yourself) for easy upgrades, etc. If you don't, then you're better off shipping a much simpler portable version of your game.

.deb and .rpm packages are basically archives right? Couldn't you extract them yourself?
We tried that, and it was more trouble than it was worth.


Can we *also* distribute a .deb package? Will download just the first linux download, or pick one at random?

Of course! Feel free to keep .deb and .rpm files on your page, itch will only pop up the policy dialog if they're the only option for Linux.

You can ship both, but mark the Deb as for no platform and mark the portable archive as Linux, so that Itch knows what to download. You can still put "Linux" in the name of the Deb package.

(1 edit)

I've squished a lot of portability issues by using the steam runtime (it's on github) to build against. They've made a pretty decent job of using only very common libs, and anything they don't include you can package up with your game.

This gets around the deb/rpm thing for my stuff at least.



Now when it comes to Linux builds of games, dependencies can in portable builds be a kind of an issue. Full packages do at least ensure these are all properly installed. Now I've been out of Linux for quite some time, but I believe there's the AppImage project to cover this up... Or is that project not running anymore? Since I'm interested in porting the projects I'm doing now to Linux it will be nice to know what the best method of distribution will be (as that has always been a bit of pain in Linux).


As active Linux desktop user I can tell I see the AppImage format quite often. Even some tools here on Itch use it. Tiled for example ports as AppImage. But I have no idea how it handles package dependencies. If you like to play it safe, distribute your game as deb or rpm package as well as a tar.gz archive (for the less popular distros). If possible, include a readme in the tar where you list up all your deps and requirements. I think you basically got it covered well enough that way.

(1 edit)

Thank you for your time. The dependencies I work with now should be rather common (zlib and SDL2, (plus SDL2_Mixer and SDL2_Image)), but since I do not know what the future brings. Linux ports are not even a promise yet, but a friend of mine who is a real geek (and he even takes pride in that, so I can safely say that) did already say he'd help me when the time comes. Yet I do see that AppImage can still be a good way to go to make sure "nothing can go wrong"... well it sounds at least most "fool-proof" to me, at least for the itch app. A deb/rpm may still be an option as separate download for the more "purist Linux user" I guess... ?


Yeah, AppImage solves a lot of distro portability issues, and it’s gaining popularity.

However, there are forward/backward compatibility issues with core Linux libraries like glibc. It’s possible to use alternative C libraries etc, but generally it’s easier and more future-proof to run a Windows build in WINE, lol.

For now I’m distributing a ZIP file with both Linux and Windows binaries to cover all the bases, an AppImage more for convenience, and thinking about an Itch installer build.

Thank you. Well, since I only have Linux on a virtual machine right now, things are hard for me to test. All I can do is see if stuff compiles and, that's it.  Running a Windows build in WINE, eh? Yeah, I guess that's always an option, though I'm not sure if this could cause speed issues.


No speed issues with WINE; it’s not an emulator, just a (partial) replacement for OS functions. The problems are always about compatibility. It runs demanding games like Witcher 3 just fine, as well as Windows builds of most Unity/Unreal/Godot games.

I find it convenient to develop in Linux and test mostly in WINE - however, it’s more forgiving than real Windows so it is necessary to test on Windows occasionally.

Well the core engines of my most recent work are coded in C++ lately with SDL2 for graphics, audio and stuff like that, and I guess given the popularity of SDL2, I don't expect too much issues in WINE. Or am I thinking too optimistic now?

SDL? If it works in Windows it should work in WINE. It’s more of a problem making portable Linux binaries because SDL has tons of dependencies, especially audio. Disabling SDL’s audio and using Miniaudio instead would probably solve 90% of those… although Linux core libs (glibc etc) cause so many backward/forward compat problems that WINE is (almost) preferable.

Would almost make me think that if I were to create a .deb or .rpm file that I should make it just install the Windows binaries with WINE as a dependency, and using a Shell script as startup file which would automatically start wine with my games. 

(1 edit)

Has there been any movement in this area? There's a Flatpak package now, and I'm sure the maintainers would be interested in helping to make things work better. I've done quite a bit of work with Flatpak too, and can give pointers where necessary.