First of all, it’s great to see you here in our corner of the Internet @probono!
There are certainly use cases where being able to bring around programs and execute them wherever they are supported. The problem most of the time is that it often leads to a mess of executables, libraries, and resources being scattered all over filesystems. The nice thing about AppImage is that it is self-contained, as you’ve explained here:
This reduces the potential clutter of portable apps significantly. Unlike other similar technologies like Flatpaks and Snaps, AppImage still tries to integrate with the underlying system in a portable way. Would it be possible to do system integration in Haiku?
Here are the possible reasons:
It is a convenient format that is self-contained and very portable.
It can integrate with the system without sacrificing anything significant.
It is a tested and widely-used method to package portable applications in the open-source world.
I’m sure people smarter than me can give better reasons than the ones above.
Thanks for your warm welcome. This is an interesting project indeed.
Looking at haiku/src/add-ons/kernel/file_systems/userlandfs at master · haiku/haiku · GitHub it seems that FUSE is available on Haiku, so it may be possible to port AppImageKit to Haiku. Further it looks like Haiku uses the ELF binary format, which is convenient since the AppImage runtime does a few ELF-specific things (though nothing in AppImage is inherently ELF specific and could not be extended to use other binary formats as well).
Why would you do this? Haiku is not a Linux distribution, we have one major ports tree and everything else depends on that, so the major purpose of AppImage in providing “universal” binaries does not apply to us at all.
Additionally, FUSE incurs a major performance penalty over kernel filesystem drivers, so why not leverage one of those? I don’t know about what drivers you can or can’t rely on in Linux, but at least on Haiku, we have packagefs, and so you can just create your own “fat HPKGs” and mount them wherever you like using mount -t packagefs my_app.hpkg ....
If you want to integrate with the OS, what about this:
Put your app hpkg into home/config/packages
Use the app
When you’re done, remove the hpkg file from home/config/packages
App is cleanly uninstalled.
If you start thinking about using an alternate format to hpkg, no matter what you try, you are not integrating with the OS package manager anymore. So just use a plain zipfile or even an iso9660 or BeFS filesystem image (which you can mount by double clicking, a bit like dmg files in MacOS). Use existing tech instead of adding yet another format.
Not everyone likes a package manager. The Mac has been doing well without one. On the Mac you do everything by drag-and drop, and applications can also run from e.g., a USB stick or from a network share.
Indeed Haiku is in the beneficial situation that there is no need to design a solution that has to work on multiple non-cooperating Linux distributions. Which means that if the design goal was “create something like .app in .dmg but for Haiku” other technical choices can be made regarding the implementation than for AppImage on Linux.
You can do the same on Haiku; just drag and drop the package file into /system/packages and the apps will appear in /system/apps/, or just double-click the application to start it from a USB stick or network share…
HPKGs also could function as “.app in .dmg”, but why would you use them that way instead of just installing them as intended?
Not a big deal, just go and define how it should work, implement it, and if some changes required at Haiku side, send your changes to the gerrit and it will be reviewed and merged to upstream. Easy!
We only need supporting extern sources like CD, DVD, USB hdd in haiku depot so you can install apps and there dependencies from local drive and not from the internet (if not available).
People can evebtually Set up a repo that then störend on a cd or DVD…
You are all thinking in installing, whereas i was talking about a drop ip, run, go away. Delete the app file itself after closing it and you are done, no traces, no orphan dependencies. Just like plug your usb, run the app, system untouched.
If you have the dependencies in package format with the app, you can just double click em locally and install it, that’s not the case.
It’s mostly solved with Haiku possibility of having the libs aside (using a environment var or not), and curious precedence of running the binaries on current folder before system ones. So you could have a folder with APP and required_app binaries, even if your system has required_app_v2.
What you are missing is our package system allows this. When you install an app, it is just copying the hpkg file to /system/packages. When you remove that package, the app is removed. No leftover files, etc.
Well-designed Haiku apps need no dependencies besides what’s already included in the system.
We don’t want to advertise the “lib besides app” approach because it just makes it harder to do security updates when a problem is found in one of the libraries. As a result, don’t expect the Haiku team to take additional effort in making this happen, further than what we already have.
Example App HPKG requires SDL, SDL is autoinstalled. Manually removed App from /system/packages . Haiku now has SDL in limbo, waiting for it to be used.
However, I think that the moving files to the /system/packages feature is great. I normally do through scripts when i craft the recipes for porting apps or micro apps to test in my own system(s). More microapps than I post, so I dont fill the forum unnecesarily.
Included now, may need to change later. You might reinvent the wheel restricting to a pure Haiku core (despite that statement being right, apps should be done with minimal dependencies).
Always expecting the Haiku team to do nothing for anything that I proposed, doing it myself if so (it’s still a standalone feature, doesnt need a backend from the os itself). For now, i just needed a hand (thanks btw) to get the ball rolling on coding here.
Just wanna see if I was going to be followed with torches if I made some experiment like AppImage or port it.
No, i just mean having your normal haiku install and test something like a electron app in an usb. Not having all as a readonly / live cd like system. (This is just PortableApps in Windows case).
You test it, it works fine, you can delete the folder. It could be made in a recipe for a system hpkg later, it might be a lame app to do something that doesnt worth a recipe but fulfills some special need.
Doesnt really matter, as I said, if you can bundle libs aside your executable in a “easy” way (as explained by Pulkomandy and Waddlesplash among others), all in a folder.
That doesn’t makes any sense, if you want auto-remove functionality, one doesn’t have to came up with a new container/fat binary, whatever buzzword format, it should be implemented in libsolv/package kit, so after every package operation it would check for unneeded packages and let the user decide, what should happen with them.
Again, there is no need for install nor touching the system, no need to uninstall either if you can just have a folder.
I just want to run the app, not have it installed. If you are going to install something, just use the package manager features like always. An hybrid procedure is fugly.
Have you run a portable app from an usb in Windows os? Just fire and forget, doesnt care about installing/removing files.
@extrowerk Yup, if dealing with automount / autoinstall that should be the way (pkg kit integration).
Mmmh i does not understand you. You want to test programs without installing it, ok. You want to test without Installation of dependencies, but this is not possible if you need them. In non-packaged folders you can copy you files to run them if you want to test them in the system folder hirachy. You can run them from a other device too, but it must be a bfs filesystem. Is it that you are asking for, make haiku programs Runable from non-bfs filesystem? My idea with the Script are for testing in the system hirachy.
