Support for a fat application format / bundle

As much as I adore the idea and the execution behind the .hpkg format, I would love AppImage to be available on Haiku. If Haiku could run current AppImages as is, it would be a huge plus, as the popularity of AppImages raise significantly nowadays.

You can just run GIMP/Glimpse or Firefox with a double-click. How cool is that…

Also, as a Mac guy, I’d love the freedom to move my applications as I please.

1 Like

AppImages are almost the same functionality as you would find in a .hpkg except that it can be executed / run directly upon double clicking and can be used for installation, where as hpkg only focuses on the latter.

I won’t mind seeing hpkgs having the functionality of also running apps (with dynamic libs contained in a hpkg) directly like AppImage but I also won’t be against bringing AppImage to Haiku but only as a third-party alternative.

1 Like

It’s important to understand that the ability to package apps in the App image format for Haiku would not magically allow you to run AppImages compiled for Linux. AppImage is just a specific way of bundling applications, but the application still needs to be compiled for Haiku.

As I understand it this is already possible. You can package an entire app including the dependencies inside a hpkg.

You still need to install it before using it.

Also, there’s a reason we decided to not do this. It’s one of the very few things we decided against when designing the package system. There are two main reasons for that:

  • First, it makes security updates and bugfixes complicated. When there is a bug in a library, you have to rebuild all packages that bundle that library. And with AppImage, the idea is that it’s not up to the Linux distros to manage it, but to the app developers. So the developer of the library must contact all app developers, and tell them “hey sorry we released this lib with this annoying bug, could you please update your package?”
  • The second reason is, the idea of Haiku is that we should provide with the OS a good set of base APIs for people to write applications. So, in fact, most applications wouldn’t need much dependencies at all (Python calls this “batteries included”). I would say we are, in a way, on-purpose degrading the experience of using Linux apps with their lots of dependencies to push native apps, which usually don’t need a lot of things besides the base system. Of course, we are now waiting for the other side of this, that is, for the actual native apps to come and use that unfair advantage :slight_smile:

On the ability to double click an hpkg to run an app, that could be done, either by silently installing it to the system, or mounting it in a separate packagefs which could still access all the system libraries. Even if the package has dependencies, this shuold work (it would just download and install them as well). And, as I said, for native apps, there would usually be no dependencies anyway. And ideally, all the app data would be in resources inside the executable, so you don’t actually need a package at all. But it turns out, having a central place to manage and update your apps overweights the benefits of that, and that has become the main way apps are distributed now.


It’s important to understand that AppImage is meant as a solution or workaround to the problem of cross-distro packaging on Linux. Nothing of the sort occurs on Haiku, since there are no distros of it (currently).


The only “issue” with hpkgs, I think, is that they are read only, unlike .app images on Mac, for example. Otherwise, you should be able to include all static linked libs and resources. Settings / user data can be stored in /home/config/[appname] folder.

Immutable systems have some downsides, but your idea would mean one or more from the following:

  • mistakenly sharing your settings with others if you share any package. For example your ssh keys. Do we really want to think about this every time if we upload/share packages?
  • the user would need to backup the packages instead of his settings. Do you really want to backup the whole libreoffice package only to back up your language settings?
  • writeable packages could open an attack vector for viruses
  • impossible to update packages, because they contain user data. How to split them?
  • no way to boot a clean state anymore.
  • many more aspects, what will seriously bite you

Also you can already repackage programs with their runtime dependencies, no need for writeable packages for that.

1 Like

Keeping the dependencies in the packages is a terrible idea. I think maybe it’s mentioned further up in the thread, but Linux has the problem where old binaries/packages don’t work on new systems only because the distros can’t be bothered/don’t have the man power to support many versions of the same libraries, they always focus on the newest. So it is frustrating if you can’t run a game from 10 years ago because glibc has been updated and the API changed, but that is actually the distros fault for not keeping the old package around. Haiku is already better at this, keeping many versions of the old packages around, perhaps as a consequence of supporting BeOS software.

This will be the case if the program is dynamically linked to libroot/libc/glibc/System.dylib and the libc API has changed. It’s a worse problem for software that is closed source than if it were open source software since in the case of the former, the OS would need to be ABI compatible to prevent these breaks and a backwards compatible API to avoid these breaks if the OS vendor plans to change the API, hence Windows’s track record of backwards compatibility since Windows 95.

It would be nice to see ideas like hpkgs being directly executable which make it have the executable nature just like AppImages, but I guess it would be just simpler for app developers to provide two ways of distributing their apps for the user; Suppose they are not using HaikuDepot and they are using their own download page for Haiku support, they serve:

  1. A typical HPKG that is installable (Or in the future, that is directly executable, like AppImage, .app bundles, etc)

  2. A portable statically linked app. (No installation step and common in some Windows Apps)

There are pros and cons to each of these, but I think having both options to the app developer would be a good thing if they don’t want to use HaikuDepot or they want to distribute 3rd party closed-source or commercial software.


On the topic of ABI compatibility, it’s important to remember that we handle this differently than Linux.

In Linux, the kernel ABI is always backwards compatible. This means your statically linked app, even if you compiled it 25 years ago, will still run on a current Linux kernel. So, in Linux, the statically linked approach indeed is useful.

In Haiku, the stable ABI is one level higher. What we guarantee is that Haiku provided libraries (,, …) ABI will remain binary compatible. But syscalls may change. This means, if you want your app to continue running in the long term, your better choice is to use dynamic linking, at least for these libraries.

So we can’t apply the linux flatpak/snap/whatever way 1:1 to Haiku, the system we’re working with is a bit different.