One AppImage to Rule Them All

[vishnu350]

Why AppImage for AM?

1. Enhanced Security: All official scripts are bundled inside the AppImage (using SquashFS), making tampering significantly harder. Paranoid users can easily verify integrity via a single-file checksum.
2. One-Click Installation: The INSTALL and AM-INSTALLER script is embedded directly into the AppImage. Upon execution, it automatically prompts to install itself as either AM or Appman.
3. Beginner-Friendly: New users migrating from Windows will appreciate the self-installing nature, avoiding complex terminal commands. Many already use tools like Gear Lever, making this a natural fit.
4. Set an Example: As the largest AppImage-based package manager, AM can set a strong precedent. This will encourage other developers to adopt AppImages for distribution.
5. Bundle Essential AM-Utils (Planned): We can bundle all essential static utils such as wget, curl, sha256sum, etc. This further improves security, portability and execution speed as am-utils binary downloads wont be needed.
6. The Green Tick (Planned): We will finally be able to add a green tick for AM!
   ◆ am | 10.5 ✓ | static-binary | 1.14 MiB

AppImage Limitations

1. No Devmode Support: This build targets end users, not developers.
2. Architecture-Specific (Not Portable): The standard script-based installation remains the recommended method for cross-architecture or portable use.

Implementation Overview (Methodology)

1. We build APP-MANAGER-*.AppImage:
   • Build command: ./appimage/make-appimage.sh x86_64 10.5
   • Integrate AppImage build related files into the repository.
   • Copy .desktop, modules/, INSTALL, AM-INSTALLER, and icons into $APPDIR.
   • When double clicked — if AM/Appman not installed, it opens a terminal and triggers install scripts, else it opens a terminal and brings up AM/Appman -h.
   • If invoked from shell/scripts/cron — Acts as AM/Appman accordingly.
2. APP-MANAGER script changes:
   • Added $IS_APPIMAGE flag to detect AppImage runtime.
   • Updated module paths to use $APPDIR/share/modules (internal to AppImage).
   • Disabled _sync_modules when $IS_APPIMAGE exists.
   • Disabled devmode when $IS_APPIMAGE exists.
3. Install scripts modification.
   • If $APPIMAGE exists, move APP-MANAGER-*.AppImage to install location (/opt/am or /home/...).
   • Skip modules installation.

TODOs

• [DONE] Add CI/CD workflow to auto-build and release APP-MANAGER-*.AppImage on version bumps.
• [DONE] Complete _sync_amcli to fetch and install the latest prebuilt AppImage to $CLI_PATH.
  • Method: mv old-am-appimage $AMCACHE/$CLI/appimage.bak && mv new-am-appimage $CLI_PATH. This preserves the old inode (/tmp/.mount**) until exit, allowing safe updates.
• [DONE] Extend architecture support (ARM, i386, etc.).
• [DONE] Bundle essential static am-utils binaries, as needed.
• [PENDING RELEASE] Add green tick for AM after zsync file is uploaded.

For those interested in testing, here is the release.

[vishnu350]

AM AppImage demo build/tests.

output.mp4

Of course, regression tests are fully passing for the built AppImage file.

[vishnu350]

Simulated updates: am -s or appman -s

output.mp4

[ivan-hc]

Why AppImage for AM?

1. Enhanced Security: All official scripts are bundled inside the AppImage (using SquashFS), making tampering significantly harder. Paranoid users can easily verify integrity via a single-file checksum.

OK

2. One-Click Installation: The INSTALL and AM-INSTALLER script is embedded directly into the AppImage. Upon execution, it automatically prompts to install itself as either AM or Appman.

It is a bit tricky, people would be able to launch AM or AppMan separately

3. Beginner-Friendly: New users migrating from Windows will appreciate the self-installing nature, avoiding complex terminal commands. Many already use tools like Gear Lever, making this a natural fit.

This is a Terminal program, so this should be able to launch a terminal. In X11 and Wayland.

4. Lead by Example: As the largest AppImage-based package manager, AM can set a strong precedent. This will encourage other developers to adopt AppImages for distribution.

What could encourage others to create AppImages is the fact that people would find and update them easily, and AM is already giving this. No centralized solution was provided before with this ability for all domains.

5. Bundle Essential AM-Utils (Planned): We can bundle all essential static utils such as wget, curl, sha256sum, etc. This further improves security, portability and execution speed as am-utils binary downloads wont be needed.

AM-utils are for x86_64 and aarch64 only, and are not 100% working as expected. They are still experimental and without a strong update process that would create them quickly.

The best solution would be to build the AppImage on a distribution (Arch Linux for example) using a better runtime (like sharun) and for all architectures (including i686, and armv7l of which the first app has been added only yesterday and for which I have no knowledge and no hardware/VM from which I can do tests and for which I'm not sure that all dependencies are available).

The classic script approach is the only one that could guarantee the compatibility with one file. This is true portability.

6. The Green Tick (Planned): We will finally be able to add a green tick for AM!
   ◆ am | 10.5 ✓ | static-binary | 1.14 MiB

...it would be enough to add a checksum file in the AM repository and made the comparison. A function that could check this and the modules would be enough.

AppImage Limitations

1. No Devmode Support: This is alright, since this build targets end users, not developers.

This is not the problem. The problem is to guarantee quick bug fixes if needed. Things that can be done with a modular scripts system like this one.

2. Architecture-Specific (Not Portable): Also acceptable. The standard script-based installation remains the recommended method for cross-architecture or portable use.

It is not acceptable, because people would see that the app is only available for few architectures.

Also if of niche, all matters. And one script aims to be inclusive.

TODOs (Help Needed!)

• Add CI/CD workflow to auto-build and release APP-MANAGER-*.AppImage on version bumps.

Workflows may fails, and often github fails if a runner is not available at very start.

The in-repository script is always available, and for all architectures.

• Complete _sync_amcli to fetch and install the latest prebuilt AppImage to $CLI_PATH.

Installing each single module separately is faster and secure, expecially if we add checksum for them all.

• Method: mv old-am-appimage $AMCACHE/$CLI/appimage.bak && mv new-am-appimage $CLI_PATH. This preserves the old inode (/tmp/.mount**) until exit, allowing safe updates.

• Extend architecture support (ARM, i386, etc.).

Let see.

• Bundle essential static am-utils binaries, as needed.

• Add green tick for AM after zsync file is uploaded.

I already answered above. About the zsync file, no matters if this format or a .txt file, it is enough to have SHA code that could be compared. And I think that this is the way to go.

[vishnu350]

This is a Terminal program, so this should be able to launch a terminal. In X11 and Wayland.

I used x-terminal-emulator inside the AppRun entrypoint, integrated into the customized portable2appimage.

...it would be enough to add a checksum file in the AM repository and made the comparison. A function that could check this and the modules would be enough.

Yes. I was thinking of end-users (tech-savie ones) who tend to validate the checksums manually every now and then. Also, third party tools like AM-GUI will also be able to do it.

Installing each single module separately is faster and secure, expecially if we add checksum for them all.

Currently all module+APP-MANAGER can be modified by any app with user permissions, so it is slightly less secure.

Workflows may fails, and often github fails if a runner is not available at very start.

I was thinking we only need release once every new version and keep it that way for stability.

[vishnu350]

It is a bit tricky, people would be able to launch AM or AppMan separately

AppImage double-click behavior (from desktop):

1. If AM/Appman not installed — Opens a terminal and triggers install scripts.
2. Else — Opens a terminal and brings up am -h

AppImage shell execution behavior (inside a terminal):

1. Behaves as am if in put in /opt/am, else defaults to behaving as appman.
2. APP-MANAGER-*.AppImage setup triggers installation scripts.

For more info, see the AppRun of the AppImage.

After installation the AppImage is moved away to the selected install location.

[fiftydinar]

I didn't mean to open the PR yet, but I did to improve AppImage deployment that @vishnu350 started:

#2698

There are some stuff that I need to know and notes:

• How do you want AppImage to be released? automatically or manually like you currently do with AM?
• How do you want double-click to behave? Currently, it just launches appman -h, while running it in terminal just launches appman itself. Modules are updated normally like regular script, they are not bundled in AppImage.
  For installation of it as script, I support setup|--install|install-am flags, especially if someone wants am. I will see if I can symlink am and support it in AppImage scenario too apart from script install.
• I don't bundle notify-send, because it bloats AppImage size, however, I bundle everything else.
• When AppImage is detected, it uses appimageupdatetool to update/sync itself. I can bundle this, I think it's worth it, it will increase size just a little bit:
  https://github.com/pkgforge-dev/AppImageUpdate

[ivan-hc]

There are some stuff that I need to know and notes:

• How do you want AppImage to be released? automatically or manually like you currently do with AM?

I would prefer to have it via push, or at least in a continuous tag (versions in "releases" are for announcing more details about new features... I must write them myself). The AppImage should already have all bugfixes of the script. This every time that APP-MANAGER and .am scripts in /modules have changes.

• How do you want double-click to behave? Currently, it just launches appman -h, while running it in terminal just launches appman itself. Modules are updated normally like regular script, they are not bundled in AppImage.
  For installation of it as script, I support setup|--install|install-am flags, especially if someone wants am. I will see if I can symlink am and support it in AppImage scenario too apart from script install.

A terminal that says "run -h..." etcetera? Its an idea. Anyway, we don't know if it will act as AM or AppMan: it is completely different.

• I don't bundle notify-send, because it bloats AppImage size, however, I bundle everything else.

OK, do not add it... or at least use it if the command exists on the host.

• When AppImage is detected, it uses appimageupdatetool to update/sync itself. I can bundle this, I think it's worth it, it will increase size just a little bit:
  https://github.com/pkgforge-dev/AppImageUpdate

To bundle appimageupdatetool (like the other dependencies) would be the best practice.

[vishnu350]

Hi @fiftydinar, thanks man for helping out! I think your sharun+uruntime and yml/hooks are nice. Right now I'm using @ivan-hc portable2appimage because the resulting size is so small (1.14 MB). It even works on really old machines, no problems.

How do you want AppImage to be released? automatically or manually like you currently do with AM?

Our target user group: End-users that will never, ever install AM scripts via command line. Basically 99% of the world's population. They just want to double click something after visiting https://portable-linux-apps.github.io, and even that is scary to them.

So, these guys don't care for latest builds or portability. They wont have a github account to complain about anything. We just have to provide a stable release for them that "just works".

How do you want double-click to behave?

When double clicked — if AM/Appman not installed, it opens a terminal and triggers install scripts, else it opens a terminal and brings up AM/Appman -h.

Here is my AppRun (embedded inside portable2appimage):

#!/bin/sh
HERE=$(dirname "$(readlink -f "$0")")
if [ -z "$1" ] && [ ! -t 1 ]; then
    if command -v am >/dev/null 2>&1 && [ -e /opt/am/APP-MANAGER ]; then
        AM_EXEC_CMD="am -h"
    elif command -v appman >/dev/null 2>&1; then
        AM_EXEC_CMD="appman -h"
    else
        AM_EXEC_CMD="$HERE/AM-INSTALLER"
    fi
    for TERM_CMD in x-terminal-emulator\ -e gnome-terminal\ -- konsole\ -e xfce4-terminal\ -e mate-terminal\ -e lxterminal\ -e terminator\ -e urxvt\ -e xterm\ -e; do
        if command -v "$(echo "$TERM_CMD" | cut -d' ' -f1)" >/dev/null 2>&1; then
            exec $TERM_CMD sh -c "$AM_EXEC_CMD; printf '\nPress CTRL+C to close this window...\n'; sleep 1h"
        fi
    done
else
    if [ "$1" = "setup" ] && ! command -v am >/dev/null 2>&1 && ! command -v appman >/dev/null 2>&1 && [ ! -e /opt/am/APP-MANAGER ]; then
        exec "$HERE/AM-INSTALLER"
    else
        exec "$HERE/APP-MANAGER" "$@"
    fi
fi

[vishnu350]

A terminal that says "run -h..." etcetera? Its an idea. Anyway, we don't know if it will act as AM or AppMan: it is completely different.

It will work as AM if am is detected, or if /opt/am/APP-MANAGER exists. Else it works as Appman. I demoed it in the video.

The code changes to existing scripts are very minimal (APP-MANAGER, INSTALL, AM-INSTALLER), only 30+ lines changes to make this work.

[vishnu350]

@fiftydinar, @ivan-hc, please take a look at my changes:

1. I have merged the YML workflow and switched to quick-sharun from @fiftydinar and got it to work. Please take a look at the binaries in my fork release section.
2. Added all essential/optional coreutils into the AppImage binary. Deleting these from the system will now have no impact on AM, it will not ever need to download am-utils.
3. Re-implemented am -s for AppImage without using appimageupdatetool to keep the final binary small, with checksum integrity validation.

From a security and functional standpoint, this build is working very well. It passes all regression tests on Debian Jessie.