Proposed development “Application Bundles”

(Use Google translation)
At present, the haiku-os function is very powerful, almost able to meet the daily function of the use, thanks to all developers.In daily use, I found that when installing some software is not very convenient, it is recommended to develop Application Bundles as a supplement to the current HaikuDepot.

The software package dependence is very troublesome, now HaikuDepot also has a dependency problem; such as SMPlayer in HaikuDepot repo Mplayer, QT on the official and so on; when installing SMPlayer, need to download a lot of dependencies, when a dependent changes, SMPlayer will not be able to install.

At the same time, when the user does not have the network, can not install smplayer.

However, if the use of a self-contained Application Bundles, there is no dependence, when the user does not have the network, the user can also use the U disk to copy the software, the direct use of.

Also, when the haiku-os system upgrade software version changes, you can also avoid the software version before and after the incompatibility caused by changes in the dependency relationship, and can not install, run some software.

In fact, when SMPlayer in hrev50701 dependencies can be met, but to hrev50767, Because Mplayer relies on the libpng library, it is not installed properly.

At present, Linux system has been developed to solve the dependence of software, Flatpak.

Therefore, it is recommended that the official development of Application Bundles.

1 Like

Well I’d suggest to actually report problems (like in instead of pushing for alternatives.

1 Like

There always should be alternatives, especially since HPKG format supports self-contained app bundles (it’s just a matter of putting all the libraries into the package). Linux-style dependency hell is not mandatory, and even if the main Haiku repo guys will go nuts, you can always set up your own repo with self-sufficient packages.

1 Like

My understanding is that Flatpak provides a chroot sandbox, to run possibly insecure versions of libraries. This is actually an alternative that Haiku doesn’t provide at the moment. Feel free to investigate how much it would take to implement, and even submit a technical proposal.

Isn’t that very similar to what haikuporter does to create the build environment for packages? That would mean doing it is just a few python scripts away, right?

You can use the hpkg system for this, if you don’t mind duplicating a few files.

Yesterday I ported two old BeOS SDL games. There are a LOT of variations of the SDL libraries floating around and you just have to try each one and test them. When you find a combination that works, you create a local lib folder that once installed, will become /boot/system/apps/MyApp/lib. Then just copy or symlink your libraries in there. It’s not an ideal situation and it should not really be used for new developments, but as a stopgap solution for old apps without source code, it works well.

If you look at the environment variable LIBRARY_PATH, you’ll see that the very first entry is %A/lib. The %A notation is new to me, but it shows up before any of the hard-coded library folders and this seems to be what does the work here: “look for a local library folder before you try the system ones”. Looks like that will work for add-ons too, though I haven’t tried it.

However, your problem of incompatibilities between different hrevs is really a problem we have created for ourselves. We are using the nightlies as a makeshift rolling-release model, which it is not. If you don’t update to the latest hrev once a week, yes, you are going to run into such problems. Once there is a stable beta, we will all use that, there will be bugfix-only updates, and that problem will go away. The nightlies will once again just be there as testing platforms for the system devs.

Unless they keep us waiting for beta2 for four or five years, of course. Then we will all start switching to nightlies once more and we’ll have this discussion again. :grinning:

Sure, if we wanted to we could develop the Haiku equivalent of Mac OSX app bundles. If hard drive space is not a consideration, that model works well. But don’t be too quick to dismiss the hpkg system. The more I work with it, the more I like it. A Mac bundle will casually include an entire Python or Java version inside the folder masquerading as an app. That is just contrary to the whole Haiku small-and-light philosophy. What we have is a middle way between that and the swarms of symlinks that infest Linux.


If application bundles would be something like what I use on my beloved Mac, then yes, I’m definitely for it on a non system-wide level (i.e. up to the developer and/or packager whether to do it or not). Maybe even self-contain dependencies and libraries inside the app, and if someone doesn’t want the app anymore, they can drag it to the Trash. (And delete any residual files in a “Library/Application Support”-esque folder, etc. but a utility could solve that, or Haiku could do this better.) :wink:

But if it’s anything like what Gnome or Canonical are proposing, then… no. I greatly fear it would cause incompatibilities and issues that would take months to fully resolve and work into the system. I’ll also add the last shift took a while for several people to get used to – including myself, and Haiku lost Haikuware and BeBits.

Personally, I’m just hoping Haiku can keep moving to its next stable release (i.e. Beta!) with the current packaging system, which works well for the most part. And I seriously appreciate the tireless efforts that have went into the repos/depot – it’d be demanding a lot to revise what’s been accomplished by them so far.


We are already doing this better.

Go in /system/packages, take your app here, move it to the trash. It is uninstalled. Unless some other app needs it, in which case it will ask you wether to cancel the action, or also remove that other app.

Likewise, to install an app, just drop it in /system/packages. If it needs dependencies, no problem, Haiku will offer you to install them. You can achieve the same by double clicking the package, with an interface allowing you to check it’s description and user reviews before deciding wether to install. And you can also use pkgman or HaikuDepot for managing them, if you don’t want to deal with installing and uninstalling manually.

A lot of thought went into designing this system so it would really gather the best of all existing alternatives, and add some more to that. Without getting much of the problems on the user side. There are still some rough edges (packages that are not installable, etc), but this is mostly problems with the packages themselves, not with the system. They happened because we had no experience managing a large package repo and we decided to write our recipes from scratch for everything. Now we have several people at haikuports with a good understanding of the problems we can get into, and knowing the way to avoid them in the future. So we are slowly getting through the issues. Please bear with us while we get all this sorted out and ready for the beta release.


Small exception to that: if the hpkg had a bootscript that, for instance, placed a symlink on the desktop or in the launch folder, that symlink won’t be uninstalled. But I can live with that. I don’t like desktop icons anyway.

Eventually pkg daemon or some cleaning up service should take care of all the associated files, including config files in user /home/… folders, logs, temp files and such things. That, of course, only if user don’t need them anymore. For example, I may want to uninstall the Firefox package itself, but still keep the profile folder in user/home with all of my bookmarks, extensions, settings and cache. On Mac there’s a few 3rd-party apps (AppZapper, CleanMyMac, etc) that help with removing all the garbage, along with the main .app package.

AGMS has filed a ticket about this:

This would also help 3rd party developers just offer a download on their respective websites. No need for recipes anymore, just download the app, and that’s it. Run it from anywhere. No more links to desktop in order to not to deal with the slowness of the Deskbar Menus. Just put the application on the Desktop. :slight_smile:

Seems like HPKG handles this(from what I know). It’s nice that’s it’s something built into the system.

1 Like