Full support for AppBundles from AppBundleHUB
This release sees the addition of a new database of third-party applications to the "AM" database: AppBundleHUB, and more precisely the programs in AppBundle format (see https://github.com/xplshn/pelf).
Programs in lists
Programs in lists will be listed with the extension ".dwfs.appbundle". For example, "ristretto.dwfs.appbundle" or "chromium-web-browser.dwfs.appbundle"
Option -l or list
As an exception, the list will be accessible using the existing --toolpack and --all flags. Here is the output with the --toolpack flag
...this is the only case where you will need to use a flag.
Since the list is still small, I preferred to merge them into a single list. The programs in AppBundle format (so with the extension ".dwfs.appbundle") will all come from AppBundleHUB.
Option -q or query
Unlike -l, programs in AppBundle format will be searchable normally (i.e. without flags) with the -q option, therefore alongside the applications in the "AM" database
...note the programs with the extension ".dwfs.appbundle", this will serve to distinguish them from those in the "AM" database.
Completion
The reason for adding these extensions is not only to distinguish them, but also to quickly list them using BASH/ZSH completion
simplescreenrecorder-2024-11-27_18.36.09.mkv.mp4
...you won't have to work too hard to distinguish them from the lists.
The listing is the only reason they have the extension... but the installation is a different thing. See the next paragraph.
-i or install option
No flag is needed, AppBundles will be installed only if followed by the extension ".dwfs.appbundle", and they will be installed WITHOUT EXTENSION
...and yes, the information in -a will also be reported in more detail. See next paragraph.
-a or about option
AppBundles will have the privilege to also show the "real" package name, whether they are installed or not
As with Toolpacks, apps from AppBundleHUB will see pages created on the fly, using the list provided by the owner of that database. Thanks @xplshn
A small aside, the -a option in general has also undergone major structural changes. Now the information will be displayed in a clearer and more pleasant way... assuming that the pages in use are up to date (I'm talking about the "AM" database, I need a hand with my catalog).
Option -f or files
Of course, the list of installed apps will also show that the apps come from a different database ("DB" column) and a new file type called "dwarfs-appbundle"
For those who don't know, AppBundles are POSIX scripts compressed with "DWARFS" and that contain the entire application. With a powerful enough text reader, you can read their content. They literally represent the statement "one application = one file".
To learn more about this topic, I invite you to visit the "Pelf" repository, at https://github.com/xplshn/pelf , a tool that can create this fantastic packaging format.
Conclusions
Portable programs are always welcome in "AM", no matter how many formats they are. As long as there is "AM" to distribute them, you will have no reason to complain about too many packaging formats.
Flatpak only supports .flatpak, Snap only supports .snap, APT only supports .deb... etc. etc.
"AM" is more inclusive. It accepts these diversities that are not tied to a package manager. An AUR helper does the same thing, but only for Arch Linux. Here instead we want to allow all GNU/Linux distributions to use the same programs according to their efficiency.
What does AppBundle have more than others? I know that it also works on Musl distributions, while many programs, and probably most of them... are written to work with GLIBC. And if you are an AppImage user, how many times have you tried to start a program that is not compatible with your version of GLIBC? Many of you will have surely received this type of error in the past.
Don't get me wrong, I love AppImages. I have 70 of them in my repositories.
With Archimages and similar I have tried to use Arch Linux containers inside AppImages, to provide recent programs that also work on old Linux systems, and precisely because they are portable containers. AppImage is also solving a lot of problems recently, and I invite you again to follow its developments, they are doing fantastic things recently. AppBundle instead was born already like this. It is still not very popular, but I firmly believe that it, like many other emerging realities, deserves due attention.
Let's give everyone a chance.
The beauty of Linux is precisely this: diversity!
What's Changed
- Added Programs by @Sush-ruta in #1153
- Add NixAppImage support by @ivan-hc in #1154
- update the ryujinx situation by @Samueru-sama in #1155
- add cromite by @Samueru-sama in #1158
- "AM" 9.1.3, full support for AppBundleHUB by @ivan-hc in #1160
Full Changelog: 9.1.2...9.1.3
