From the end-user perspective - how does AM differ from zap?

[sbstn87]

Hi,

can you explain, how AM differs from zap from the end-user perspective? Both are AppImage managers, that download, install, integrate with the system and update installed AppImages.

[ivan-hc]

Hi,

there is no real difference between the two in terms of use. Both AM and AppMan are extensible to multiple architectures (being simple bash scripts), they install applications from multiple sources (and not only from the official catalog, ie appimage.github.io) and do not limit themselves to installing only AppImage packages but any standalone app already available as a bundled tar/zip/deb archive (see the various Firefox, Blender, Vivaldi and Google Chrome). Furthermore, the programs managed by AM (and AppMan) are mostly updated to the latest version, and it is possible to add specific versions of some packages (if expressly requested by the user).

PS: I want to clarify that "AM" installs applications following the LSB (Linux Standard Base) standards at system level, while AppMan installs everything locally in your user folder and in a path of your choice. Normally other AppImage managers install everything in a new "Applications" folder in the home or even in /.

[sbstn87]

Thank you for the reply.

So basically, AM is a more advanced or a more feature-rich tool than zap. I have been using zap and I liked it, so I will give AM a try.

You mentioned that AM uses multiple sources to source apps - I have seen the list of supported apps, but is the list of sources available as well?

Is it possible to add custom sources somehow? For example, if I found a GitHub repo of an app that releases AppImage or .deb files, is it possible to add it somehow to AM?

[sbstn87]

I have installed AM and use it to install a few available apps. My first impressions are very positive. I love how it "dismembers" the downloaded AppImage file and puts its contents into appropriate folders and also integrates the app with the system, adding shortcuts into the "Start Menu". In my case, it may replace zap completely (not that there is something wrong with zap, it's still very nice).

Great job.

[sbstn87]

I have just discovered the github2am script and tested it to install Ventoy, which does not provide neither a .deb file, nor an AppImage file. And to my surprise, typing "sudo am -i ventoy" after running the github2am script, did install the app correctly!

What kind of magic is this? Can I use to install any app from GitHub that publishes a .tar.gz, .deb, etc. file?

[ivan-hc]

Hi, sorry for the delay,

You mentioned that AM uses multiple sources to source apps - I have seen the list of supported apps, but is the list of sources available as well?

Yes, of course, just run am -a $PROGRAM to get info and links for each of these, or just am -w $PROGRAM to see the links only

Is it possible to add custom sources somehow? For example, if I found a GitHub repo of an app that releases AppImage or .deb files, is it possible to add it somehow to AM?

Sure, there is a -t or template option that allows you to have a basic script to upload on your fork and then merge on this repository, you can choose the option 3 for apps available on GitHub (this is the more complete and detailed) or 2 if there is the link of a binary available on the AUR (you can edit this script to made it work with links from different websites than the AUR's one)... just type am -t $THE-NAME-OF-YOUR-PROGRAM to choose a template on wich you can work, it will be saved on your desktop, the list of the available templates is in the /templates path of this repository

I love how it "dismembers" the downloaded AppImage file [...]

Thanks, for now the only two apps that are "dismembered" are kdegames and kdeutils because there I'm sure about what the names of the icons and the launcher are, I've built them, normally there are many AppImage packages that have launchers and icons with a different name if compared to what you aspect (see for example the official "Avidemux", download and extract it using the --appimage-extract option, so you can see why tools like "AppimageLauncher" cannot made it work anywhere, SPOILER, read the *.desktop file), and this is a problem for me, because the first thing each script from AM creates is a script named "remove" that contains the exact name of each file or directory installed with the script. In case the app is not installed correctly, it has download problems, you abort the installation or there is any problem related to the app's installation, you can always remove everything you have installed (the -i and -r options in "AM" are the only two needing the sudo command).

Great job.

Thanks ^.^

[...] github2am [...]

You don't really need it, just use the "am -t" command I've talked about in the first part of this message :)

And to my surprise, typing "sudo am -i ventoy" after running the github2am script, did install the app correctly!

Ventoy is already available in the database of AM for x86_64, i686 and aarch64, then you've installed it using the script I wrote time ago :)

What kind of magic is this?

Each installation script is... just a shell script, you can download it using the command am -d ventoy, the installation script named "ventoy" for your architecture will be saved on your Desktop.

For example, if I found a GitHub repo of an app that releases AppImage or .deb files, is it possible to add it somehow to AM?

Sure, just follow the instructions of the option 3 of the am -t command, at the end just test the "download" and (in case of archives that are not an AppImage) explore the content to see where are the contents you're interested in.

The template for the option 3 is this one, there is wrote everything you need to know. Just create your first script and play with it, all you need is a basic knowledge of the bash commands (really basic, ie cp, rm, mkdir, grep, cat, tar, ar, curl, wget...).

I wrote all these scripts by myself, sorry if something doesn't match the original apps (like the "launcher", which in many cases is not the original but a generic one), any fix is welcome.

[sbstn87]

Thank you for the detailed response. Appreciated.

I will be playing with AM more, it's a great piece of software.

[ivan-hc]

Another thing, once you've installed an app you own the whole content of that app, so you can manage the updates without having to use sudo. An adavantage of this situation is that you can replace the symlink (for example /usr/local/bin/avidemux) with the AM-updater itself by adding the path of the binary into the script (after the last line, normally it is fi) to made the app self-updatable, for example:

echo "/opt/avidemux/avidemux" >> /opt/avidemux/AM-updater
sudo mv /opt/avidemux/AM-updater /usr/local/bin/avidemux

the app will check for the updates each time you run it.
The disvantage of this is a slower launch of the app, depending on your intenet speed.
In the end, you have not to care about the updates each time.

You can also add some options in the AM-updater script before you add the path of your app, for example to made the fonts large enoug to be equal with your system theme, for example I have this at the end of my script to update and run the AppImages of "Avidemux" and "Kdenlive":

 export QT_FONT_DPI=100
 /opt/$APP/$APP

of course, into these scripts there is already an environment variable for APP= to specify if I want to run avidemux or kdenlive.

[sbstn87]

This is great. A lot of wonderful functionalities :)