Support for a fat application format / bundle

#1

Although Haiku has a good package management, and knowing the [common insert untrusted binary download warning here] that we know about, would be interesting to have some kind of bundled app that include the required dependencies for big apps?

Something like AppImage on Linux (or FlatPak/Snappy, but those require a server, i mean ones for standalone apps), or just port the AppImage tools to make Haiku AppImages.

AppImage at Wikipedia

Note: not remove/replace packages, but for an alternative way to have apps on the system

Ps: The world is quite small, and seems like Alexander Larsson is the author of a precursor of FlatPak and also the same author for the Broadway backend i talked about in the GTK3 topic. :thinking:

#2

Well, why not just copy packages? Thatā€™s usually what I do and itā€™s easy enough, provided the systems are the same hrev. Packages usually have what they depend on, so itā€™s usually just a matter of rounding up what you need into a folder or what not and copying it.

Personally, Iā€™m usually very open minded about new ideas, but after all the work put into the PackageFS, itā€™d be a shame to slow down Haiku development to pursue app images. Just my little opinion. And maybe others might think AppImage or the like is a wonderful idea. So, anyways, thatā€™s just meā€¦

#3

A lot of Windows applications are still distributed as a zip file with the executable as well as every dll file that the application depends on. You can extract it anywhere you want and itā€™s ready to be used. I would very much like to see more of this in Haiku.

#4

That may not be a good idea in long-term use since what happens with most users is that they will be scattered almost everywhere throughout the file system. Many will be in the Downloads/User/Home folder, others on the desktop, in a different drive, some seemingly random location, et cetera. Perhaps something like AppImage (if not that per se) would be the better approach, where all the files are stored in a container format (not containers) that can just be brought around and executed instead of extracting the contents and creating a mess.

#5

I consider this more of a good thing than a bad thing. I want the freedom to put applications wherever I want.

#6

Because you cant have (that i know of) a GTK2 application that uses cairo 1.13.x (providing pkg-config library ā€˜cairoā€™) and this new app GTK3 that rocks but requires cairo 1.14.12 (same ā€˜cairoā€™ pkg-config name). You can, so statement is not a good example.

Also, because there might not be a recipe yet for a dependency.

If the packages are available, then yes, packages all the way, just pkgman-em.

#7

Just imagine trying to play a Linux game that came out 10 years ago and hasnā€™t received any updates. It would take weeks to gather all the libraries it needs, if it would at all be possible to play.

#8

You can distribute your hpkg and the package manager will automatically download dependencies when users install it. So it works just as an AppImage: double click to install, then run. Escept it also allows us to distribute security updates without relying on the application developers to do so.

#9

Of course you can on Haiku. We ship libpng 1.2, 1.5 and 1.6 side by side for backward compatibility with old BeOS and Haiku apps, for example. We can do the same for Cairo if it ends up being needed.

You can have development files installed only for one version, but the lib can have multiple versions.

#10

As i spent most of my time on the porting / dev side, i think i just found the ā€œdevelopment filesā€ part (hence why I imagined that several versions were not so possible). Glad to be wrong.

Also, i dont mean remove package system (it works and it does very well), nor replace it.

I just meant having an alternative way of bundle one app, for one time or only some times usage, or whatever, not so much as ā€œinstallā€.

Like my portable apps on windows, or the Etcher app thatā€™s recommended for usb flashing of haiku.

#11

A binary will never ask pkg-config for a lib.
Haikuporter can use version constraint, so thatā€™s also not a problem.

#12

Good to know . Should try that on practice, when i get rid of my current recipes problems & tickets.

Then only nonexisting recipes example might apply

#13

Just put the needed files in a .zip and call it a day then. No need for something fancier. By default the OS will find libs in a ā€œlibā€ folder next to the executable so you can just put your libs there.

There isnā€™t much point in doing that nowadays I think, but itā€™s the way BeOS apps worked and itā€™s of course still supported. There is no need for a custom bundle thing when a plain zipfile does everything we need, right?

#14

Oh yeah man, that would solve a lot of use cases for what i meant.
I dont know why it wasnt done with the standard env variables for lib ā€œpreloadā€, but i would take it.

:thinking: Will the os look on the lib folder before or after checking the ā€œcommonā€ lib paths?

#15

It is. Check LIBRARY_PATH (as opposed to LD_LIBRARY_PATH).

#16

The more you know.

All that cool things in Haiku, should be put into a cheatsheet. :thinking: May be present already.

#17

Hello, AppImage lead here. AppImage is just like a zip file except that you donā€™t have to unpack it because it is a self-mounting filesystem like dmg on macOS.

#18

A zip needs to be extracted whereas an AppImage is mounted when executed. Besides this they are the same.

The real question here is whether Haiku supports FUSE. If yes, then porting AppImage to Haiku should not be a problem.

#19

Being able to execute programs from random locations is the great thing, really. Myself, I like to execute applications from USB thumb drives and network shares, for example.

The real question here is whether Haiku supports FUSE. If yes, then porting AppImage to Haiku should not be a problem.

#20

It supports, but whats the point porting something alien?