Skip to content

"AM" 9.1.3

Compare
Choose a tag to compare
@ivan-hc ivan-hc released this 27 Nov 18:12
· 12 commits to main since this release
c86b2e4

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

Istantanea_2024-11-27_18-28-38 png

...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

Istantanea_2024-11-27_17-16-41

...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

Istantanea_2024-11-27_17-22-20

...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

Istantanea_2024-11-27_16-54-46

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"

Istantanea_2024-11-27_19-50-59

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

Full Changelog: 9.1.2...9.1.3