Skip to content

Releases: ivan-hc/AM

"AM" 10.1

12 Apr 14:06

Choose a tag to compare

Towards Autonomy

This release increases the database to 3,019 applications in total (2,614 AppImages and 405 portable apps in other formats), 35 more than the previous release (with about ten removed).

This release features important new features, ranging from full autonomy, introducing its own PATH, on-the-fly AppImage creation, and support for portable2appimage.

Let's proceed in order.


Option -t

Creating install scripts for AppImages from GitHub will take into account AppImages distributed in archives (which is a serious violation of the standard, as AppImages themselves are "archives"... but many developers prefer to distribute them that way, and they're wrong). No more empty previews. You'll have to enter the appropriate keywords.

Additionally, a template for AppImages compiled on the fly has been added to include support for portable2appimage. Creating two scripts for that type of app will no longer be necessary.

#2231 #2236

Visit https://github.com/ivan-hc/portable2appimage for more info.


Option -u or update... and now also upgrade

You can now use the upgrade option to invoke -u or update as an alias.

by @fiftydinar in #2235 #2238


New custom PATH, for options -i or install and nolibfuse

Previously, if you didn't have appimagetool installed, it was downloaded every time you:

  1. installed an on-the-fly compiled AppImage (the -i or install option)
  2. converted old AppImages to the new runtime to remove the libfuse2 dependency (the nolibfuse option)
  3. updated both an on-the-fly compiled AppImage and one converted to the new runtime (see points 1 and 2 above)

From now on, this will no longer be necessary.

A new PATH has been launched for AM, which can be used while using the options above.

The only supported binary currently is appimagetool, but more are planned to be added in the future.

NOTE: You don't need to do anything; you don't need to modify any files. You just need to use the option that requires that specific binary.

The new PATH is volatile and cached. You can remove the binaries contained within it by running am -c or am clean, or by using an external tool set to clean the cache (e.g., Bleachbit).

This PATH, called "AMCACHEPATH," will only contain binaries authorized by AM. These will be removed if you have installed them and the command is present. For example, by running

am -i appimagetool

In this case, the new PATH will not be considered.

Future Plans

With the new PATH, I want to allow greater coverage of necessary dependencies, if not installed. I aim to make AM much more autonomous, and I'm already working on other static binaries, strictly exported in AppImage format. The first is Busybox, which I'm still working on. You can help me improve it by contributing to the repository below:

https://github.com/ivan-hc/busybox-appimage

It will certainly be introduced in future releases of AM.

  • "AM" 10.1 - Custom PATH for appimagetool if not present by @ivan-hc in #2250

What's Changed

New Contributors

Full Changelog: 10...10.1

"AM" 10

04 Apr 21:50

Choose a tag to compare

When the improbable is the solution to everything

This release stems from an issue from contributor @fiftydinar, who asked me to fix a bug related to updating the same app installed both system-wide and locally.

"Why would someone install the same app twice?" you might say. I was wondering the same thing, too. I never considered this possibility, as it was highly unlikely.

I was tempted to ignore it, adding something to prevent it... but then I decided to experiment and see what came out.

From that moment on, a cascade of events occurred that turned everything upside down! Stagnant bugs appeared, never really fixed or reported until now.

That's what it did: to rewrite everything and further strengthen the existing code!

But let's proceed in chronological order.

First, know that the database now has 61 more apps: 2,984 unique apps (2,578 Appimage packages and 406 standalone/portable programs). And they are truly unique. The answer is in the next paragraphs.


Improved checksum checking

Checksum verification messages are less invasive and more compact. The check is also now more effective.

Istantanea_2026-04-04_22-45-51 png


Português brasileiro adicionado

Obrigado @Link4Electronics #2138


Option -f

Applications now display decimal places in full size, for more precise calculations. Symbols (especially checksum symbols) are also more readable.

Istantanea_2026-04-04_22-51-01 png


Libreoffice

The -e option has a dedicated template for anyone who decides to install libreoffice from another GitHub repository.

Furthermore, the installation script in this database allows for the selection of many more genuine builds rebuilt from scratch.

Istantanea_2026-04-04_22-56-02 png

Other languages ​​are in the works, thanks @zen0bit

NOTE: Official builds (even if adapted) have been completely removed due to neglect to maintain the original AppImage on the official website. New builds based on the official .deb packages are based on the original LibreOffice project workflows and have been adapted to modern AppImage standards.

See https://github.com/Portable-Linux-Apps/LibreOffice-appimage


Firefox and Thunderbird

Official builds of Firefox (5 development branches) and Thunderbird (3 branches) and their AppImage counterparts now share the same installation script.

Istantanea_2026-04-04_23-03-33 png

We've therefore halved this group of scripts. To install the AppImage counterpart, you no longer need to add -appimage to the app name: select 2 and press Enter. Press 1 instead for the official build.

by @ivan-hc in #2201
by @ivan-hc in #2202


Option -t

The -t option will now download lists from "main" even when in developer mode. Additionally, for apps from GitHub, if the argument is the URL, it is inserted directly, bypassing the prompt to add a reference URL.

simplescreenrecorder-2026-04-05_02.23.25.mp4

You can then add AppImage packages from GitHub by pressing ENTER five times and doing nothing else.


Option --launcher

Extract the AppImage to a temporary directory and fix support for Anylinux AppImages that were not integrated in the menu.


Manage the same application installed on multiple permission levels

As mentioned at the beginning, it is now possible to manage the same installed app on multiple permission levels.

For each appname found, the presence of a second path will be detected, based on which it will be possible to dedicate to that app, and only to that app, different managements from the same one installed on another level (for example you can keep two different versions after downgrading one of them, or keep one original and the other converted without depending on libfuse2...).

Locally installed apps will have (AppMan) in brackets, to distinguish them from system apps

Istantanea_2026-03-31_13-38-34

This implementation fixed many bugs, mostly related to the version not being displayed correctly or not being displayed at all in some cases.

Option downgrade Option -R
Istantanea_2026-04-04_23-21-01 png Istantanea_2026-04-04_23-21-49 png

Research has also fixed numerous bugs related to sandboxed AppImages, including support for applications with the lock option, app path recognition, unwanted terminations, half-finished sandboxing, and, most importantly, a more streamlined way to switch root permissions between a system app and a local app.

The clone (with the -i flag) and reinstall (with the --all flag) options have also been improved.

But one of the main bugs concerns messages related to local apps whose directory was orphaned, meaning it's left over from an incorrect installation, thus preventing reinstallation.

The check is very simple: all AppMan-compatible paths are selected. If a directory has fewer than 4 entries, a check is made to see if the number of executable files is less than 3. If so, the lines in the remove file are patched to ensure they don't contain paths that don't comply with the AppMan specifications, after which the directory is removed. The message will no longer appear, and you'll be able to reinstall the apps you couldn't install before.

But there's more: AppMan finally has a trap (like AM) that detects if an installation was interrupted by external causes (for example, pressing CTRL+C), and, as with AM, the incomplete directory is removed.

The unhide option has been improved to intercept paths and differentiate between local and system apps.

Regarding the -o or override option, the AM-updater/AM-LOCK file and the remove file are preserved, to avoid exchanging backups between local and system apps.

by @ivan-hc in #2204


Conclusions

I learned one thing from this experience: Never underestimate an issue. Even the seemingly silliest one can prove useful for exponentially improving an entire project, and yourself.

What's Changed

Read more

"AM" 9.9.5

09 Mar 04:40

Choose a tag to compare

Checksum on the installed programs

With this release, the database has 81 new programs, and the number of unique apps has increased to 2,923 (2,505 AppImage packages and 418 programs in other portable formats).

In addition, we've introduced the first experimental checksum support for installed programs. These will appear in all options that display the version (-f, -i, -l, -a, etc.) if the installed app has an online .zsync or .DIGEST file to verify the checksum.

To use this new feature now, you need to update your applications with the -u option. The first time, applications will appear as if they're updated to a new version, but what's actually changed is the addition of a green checkmark to the version number, indicating that the installed app has passed the checksum check.

simplescreenrecorder-2026-03-08_03.11.27.mp4

Here's what the app list looks like with the -f option and the installed apps when running -l.

Istantanea_2026-03-08_03-13-35

Verification will be performed every time apps are installed.

simplescreenrecorder-2026-03-08_03.12.04.mp4

NOTE: If an application fails the checksum test, it doesn't always mean it's malicious. Checksum verification also serves as an indicator that apps comply with security standards and specifications applicable to modern AppImages, such as the .zsync file, which is also required to indicate that an application supports delta updates (with the advantage of downloading a few bits instead of the entire file during the update).

This new feature also serves to encourage AM's user base to contact the developers of a specific application to make it compliant.

This new feature, as I mentioned, verifies whether the checksum matches a .zsync or .DIGEST file present where the app is hosted. The application URL is taken from the "version" file already present in your app directories or the AM-updater, to avoid reaching the API rate limit if a site, such as github.com, imposes one.

Packaged apps are already subject to integrity verification, so they are automatically marked as valid.

The new feature specifically affects AppImage packages and portable programs whose host includes a .zsync or .DIGEST file.

For more, see #2125

Thanks @vishnu350 for this new feature!


How do I make my AppImage compliant with modern standards?

Do you have an AppImage package and want to make it compliant? Simply create it with the latest appimagetool and follow the instructions to also obtain the .zsync files needed for delta updates.

👇 Click the URL below for an easier tip 👇

https://github.com/ivan-hc/AppImage-tips

☝️ It's just a 5-minute read. ☝️


What's Changed

New Contributors

Full Changelog: 9.9.4...9.9.5

"AM" 9.9.4

14 Feb 19:20

Choose a tag to compare

Report outdated apps, from archived sources, and potentially vulnerable

It's Valentine's Day, the holiday of lovers and... regrets!

I won't be here to comfort you about your failed relationships (I already have my own to think about)... but let's talk about apps.

Or rather, the apps you're fond of and whose relationship you're unaware of has stagnated. Or rather, how dated your relationship with them is.

As the title suggests, from now on, all apps from GitHub repositories will be checked (every two weeks) and listed based on:

  • archive status (i.e., whether the repository has been archived)
  • when the last update for that release was made (indicating the year, if no updates have been made in the last year)

Don't worry! There are 63 more programs available than in version 9.9.3... bringing the total to 2842 unique programs (2430 AppImage packages and 412 programs in other portable formats) that can "warm your heart", who knows?!

In the following examples, we'll use skype (a repository of mine that I archived in 2025) and akasha (whose last release dates back to 2018).

OPTION Screenshot
-i or install install
-a or about about
-l or list list
-u or update update
-f or files files

NOTE, -a and -l reports the info only if the app is installed. See "How can I get the version of a software without installing it?" to understand why.

You can see the lists of archived/obsolete apps down below:

As I write this, for the sake of intellectual honesty, I feel compelled to publish data on apps in the AM database that come from github.com and whose "release" section has not received any new updates in the last 10 years:

Istantanea_2026-02-14_20-53-24 png

The lists are updated every two weeks, that is, every 14 days.


Option downgrade or --rollback, lists are now smaller (if you want)

From now on, you will be able to see shorter downgrade lists when the repository publishes releases as snapshots.

app before after
anydesk anydesk-before_2026-02-07_17-02-09 anydesk-after_2026-02-07_17-02-09
brave brave-before_2026-02-07_17-02-47 brave-after_2026-02-07_17-02-47
filelight filelight-before_2026-02-07_17-03-20 filelight-after_2026-02-07_17-03-20

A prompt will ask for confirmation to exclude "snapshot" versions.

In the examples: firefox, brave and filelight

Default is "Y" (exclude snapshots), press "n" to include snapshot versions

simplescreenrecorder-2026-02-08_00.45.53.mp4

by @ivan-hc in #2060


Option -t or template

Now the prompt warns you that an appname already exists.

by @ivan-hc in #2065

Also, for lazy users, it is possible to add the whole URL of the github repository or the releases section of the latter to extract the appname, where possible.

by @ivan-hc in #2066


What's Changed

New Contributors

Full Changelog: 9.9.3...9.9.4

"AM" 9.9.3

24 Jan 19:05

Choose a tag to compare

Small changes... big numbers!

This release brings small changes to the way the CLI interacts with the system... but also an increase in the number of apps in the database.

There are 122 more programs available than in version 9.9.2, released three weeks ago... bringing the total to 2,779 unique programs (2,368 AppImage packages and 411 programs in other portable formats).

Small fix for LAUNCHERS_DIR when using appman

In custom setups that have alternate launcher locations (.desktop files) for locally installed apps, this change fixes the issue of apps disappearing from the menu.

#2011

Add "AM-GUI"

Welcome to the first GUI for AM and AppMan, created by our collaborator @Shikakiben.

Light theme Dark theme

NOTE: This interface is still experimental and can be further improved.

To install/test it, use the command

am -i am-gui

or

appman -i am-gui

For more information and to report bugs and improvements, visit the link below.

https://github.com/Shikakiben/AM-GUI

Thanks @Shikakiben

#2006

Change the way to detect Namespaces restrictions

AM/AppMan and Archimage have one thing in common: a Namespace Restrictions check!

These restrictions have been active since 2023 on Ubuntu and many of its derivatives. They prevent the operation of many applications that use sandboxing alternatives to AppArmor, such as many Chromium-based programs... and Archimages, which can switch between using proot and bwrap if the latter doesn't have permissions.

Some changes in Ubuntu have eased these restrictions, but they have made it impossible to identify them.

To avoid blacklisting Ubuntu itself and any distribution based on it, we have changed this control in both AM/AppMan and Archimages (for which it will be effective with the next scheduled workflow run in their own repositories, starting from today).

#2044

Possible further solutions are welcome.

What's Changed

New Contributors

Full Changelog: 9.9.2...9.9.3

"AM" 9.9.2

04 Jan 16:08

Choose a tag to compare

First release of 2026

This release not only introduces 79 new apps, bringing the database to a total of 2657 unique apps (2250 AppImage packages and 407 programs in other portable formats) but also introduces some small changes.

Increased number of pages in Github after 5 failed attempts in -i or install

One of the most common bugs in GitHub releases concerns the management of pages in this section. Often, accessing them via the API defaults to displaying no further than page 3. With this change, after five failed attempts, the list will be expanded to 100 pages.

#1945

Improved identification of installed apps

#1957

Removed subshell in -f

In order to prevent unintentional program launches when testing variables (in function "_determine_args").

#1958

Improved speed in versions check and -f

#1959

Detect applications in symlinked paths

Fixed a bug related to apps installed in symbolically linked directories

#1960 and #1961

Fix missing version in AM where apps are installed in multiple levels

Although not recommended, it is possible to install the same app both system-wide and locally with AM in AppMan mode. However, despite this being an edge case, running -f did not display the version in the first duplicate, the one installed system-wide.

This bug has been fixed #1991

Determine the directory of the launchers in Maemo Leste

In Maemo Leste, launchers are located in a subdirectory of "applications," unlike other Linux distributions. With this change, the launcher directory for the menu will be determined based on the presence of the hildon-home command (available in Maemo Leste).

#2010

What's Changed

New Contributors

Full Changelog: 9.9.1...9.9.2

"AM" 9.9.1

28 Nov 13:34

Choose a tag to compare

Introduction

When I publish a release, I want each one in this section to become a step-by-step guide to what I'm doing.

Even though it's been two months since v9.9, significant changes occur in the modules, which commonly function as secondary programs on their own.

Given that over 300 commits have been made in two months, and they are growing every day (also thanks to the increase in apps loaded, but we'll see this shortly), I risk forgetting some important changes while I write my "chapters", if we want to define every release that way.

That said, here are the changes that have occurred up to this release in chronological order, and not in order of importance. If it's "important" you decide.


More modular "help" message (option -h), for translations

The "help" message is now modular, each option has a dedicated variable to easily translate it option by option.

#1839


Made ZSH completion "optional"

Since ZSH has not a secure enough way to use shell-completion (if compared with BASH and FISH), a prompt will ask you to enable this useful feature if you use this type of SHELL.

#1844


Add "integrate" (alias --launcher) and "search" (alias -q)

Many people complain about the lack of options, also if they already exist. Maybe because they don't recognize an option name for what it does.

It's understandable, the project has grown a lot, and with it the number of options and documentation, in which you get lost. There is no point in writing in the issue templates "I declare that I have read the documentation" if the latter is too... too big! I understand it. I'm actually very lazy too, like many of you.

It is the case of the option to "integrate" local AppImages by drag/drop them to the terminal (--launcher, now also integrate) and the option to "search" keywords in the list of the available applications (-q or query, now also search).

#1866


„AM“ auf Deutsch

German Language Added by @Fluke667 in #1868


Improved SourceForge support in templates and set AppImages as default choice

I've been working on a common method for detecting programs from sourceforge.net, and then a set of mechanisms for creating installation scripts that are similar to each other. Expecially for AppImages

#1889

For portable apps instead is a bit different

#1890

I exposed all these discoveries in the template.am module, dedicated to the -t (or template) option, and I took advantage of it to make AppImage (choice "0") the default. Simply press ENTER to use the template dedicated to AppImages.

#1892


Determine if the argument is an installation script (option -i or install)

To prevent users from misusing the installation options, which are intended for scripts, not random files, the argument will be checked to see if it is a script, an AppImage, or another file type.

Istantanea_2025-11-24_13-30-36

#1923


Option -t or template on "steroids"

Now all scripts will be created for x86_64 by default, but if an aarch64 program is in releases, -t will clone and edit the created x86_64 script to convert it into an aarch64 one

#1926

But this is not the only change:

  • added instructions in the "list" file
  • replace already listed item in the "list" file
  • base the entire module on x86_64 as main architecture
  • download x86_64-apps near the x86_64 directory
  • if an aarch64 directory has been created, download also the aarch64-apps file
  • fix descriptions with multiple lines
  • fix syntax of apps description
  • lowercase the first letter of the description and end it with a dot
  • if a description is blank, open the prompt to create it also for apps hosted on GitHub

To resume all the above, in this example, I use a repository that has both x86_64 and aarch64 AppImages, and a repo without a description.

I'll repeat the second one two times:

  • you will receive a prompt to add a custom description
  • if the item already exists in "list", it will be overwrited
simplescreenrecorder-2025-11-25_20.22.08.mp4

#1927


Integrity check for broken download URLs (option -i or install)

The installation scripts include an exit 1 that is executed if a URL download (via wget) fails.

This error is often due to temporary connection drops.

This change checks whether the "tmp" directory created during installation still exists, and if so, checks whether it is empty. If it is empty, up to 5 download attempts will be made, spaced 5 seconds apart.

In this example, I'm testing an installation script from a repository where the "latest" release doesn't exist, but only pre-releases, https://github.com/niess/python-appimage

During the process, I'll modify the running script (they run in ~/.cache/appman or ~/.cache/am, in my case I use am -i --user, so its a local installation, like AppMan) so that it will search for, find, and install the first generic release it finds.

simplescreenrecorder-2025-11-26_22.28.27.mp4

This will also help me with false positives in https://github.com/ivan-hc/amcheck

#1928


The number of programs in third-party databases is now more "realistic" (option -l)

Previously, third-party databases considered the total number of packages (unlike the AM database, which only counts unique packages).

From now on, the total number of commands will appear, while the lists will continue to list variants of the same command.

Before After
before after

#1933


70 new apps added in two months

While I'm writing, here you are the numbers of the "AM" database for this release:

2578 unique programs available (+70 if compared with "AM" 9.9), of these, 2175 are AppImages and 403 are other portable formats.


What's Changed

Read more

"AM" 9.9

19 Sep 22:46

Choose a tag to compare

Clone and share your configurations and relocate AppMan apps

This release brings two brand new options: one to pre-clone your configuration or install someone else's, and another long-awaited option for many AppMan users, and others. But let's proceed in order.


Option clone or --clone

The clone or --clone option allows you to detect or create a file called "am-clone.source" from which AM/AppMan can obtain the information needed to install apps from one system to another. This allows you to choose whether to keep distinct system and local installations, or whether to install everything system-wide or locally.

File detection starts (in order of priority):

  1. from the XDG_DESKTOP_DIR directory (usually Desktop)
  2. from the HOME directory (any directory except Thrash)
  3. from the entire system, starting from the root, and then from mounted devices (in case you want to install a configuration via USB stick)

If you want to create a new "am-clone.source" file, simply remove the other one or rename it.

This option supports both AM and third-party databases.

The basic command is

am clone

without arguments. This allows you to read the list.

Istantanea_2025-09-18_16-02-20

By default, the new file is created in XDG_DESKTOP_DIR, or HOME as a fallback. It contains "dummy" paths to allow AM/AppMan to distinguish between locally and system-wide installed apps (depending on whether the line starts with /opt or not).

You can also set a different file by exporting the "$CLONE_FILE" variable and specifying a path and a text file with a different name, for example

export CLONE_FILE="/path/to/your/file.txt"

But make sure the paths begin with /opt if you want system installations.

But what we've seen so far is just a basic way to view and/or create/use the list.

The new clone option also supports flags.

To install the listed apps in their original layout, run

am clone -i

or

am clone install

A confirmation prompt will appear.

Istantanea_2025-09-18_16-10-42

In AM, to install everything locally like AppMan, add the --user flag

am clone -i --user
Istantanea_2025-09-18_16-12-38

While to install everything at system level, add the --system flag

am clone -i --system
Istantanea_2025-09-18_16-14-02

Of course, AppMan only supports local installations, no apps will require root privileges or system installations.


Option relocate or --relocate

In AM, programs are always installed in /opt, following the LSB (Linux Standard Base) specifications. It is not possible to change this path.

In contrast, AppMan and "AM" in AppMan mode can install all programs locally or in non-privileged locations, chosen by the user. No root password is required for this.

The path chosen at first launch is specified in the $XDG_CONFIG_HOME/appman/appman-config file. Editing this file directly disconnects AM and AppMan from that location, thus removing any interaction with locally installed programs.

Furthermore, installed programs all have a symbolic link and (often) a .desktop file, which breaks if the program directory is moved.

The only solution is to run the relocate or --relocate option, which will allow you to:

  1. Identify local apps installed, even from third-party databases
  2. Remove these apps, noting the scripts used to install them
  3. Choose a different location to install the apps
  4. Reinstall the previously removed apps in the new location indicated

All this requires your confirmation in the prompt that appears.

Just run

am relocate

or

am --relocate

or

appman relocate

or

appman --relocate
simplescreenrecorder-2025-09-18_19.22.32.mp4

This is definitely the option that many AppMan users have been waiting for.


Among other changes

New Contributors

Full Changelog: 9.8.2...9.9

"AM" 9.8.2

08 Aug 14:28

Choose a tag to compare

Push towards third-party databases and increase in software portfolio

I've been working for a while on improving the "am-extras" repository, dedicated to AM extensions, and after receiving the first contribution, I decided to revise the programs management in the AM database.

I started by delegating the management of all Python AppImage scripts to "am-extras", and the result was amazing: while for the x86_64 architecture alone, in the "AM" database the choice was between 11 Python versions, the new "python" database listed up to 4 for each version, extending the choice to 40 different AppImage packages, and without a dedicated installation script in the AM database.

This led me to work even harder to create a system that can make things easier for you! All of you! The users!

By creating dedicated third-party databases maintained by you in "am-extras", you'll have even more freedom in adding and choosing software.

To summarize, you need a table in Markdown format with five columns. Nothing else.

Here are all the databases with the numbers of all the apps currently installable via AM so far

Istantanea_2025-08-10_20-58-39

With this approach, I've realized that AM's biggest dependency is me. Until now, to submit a simple AppImage, you've always had to wait for me to work on the script or approve a pull request.

I'll continue to do so as long as I can, but this new approach will definitely give you much more freedom to have as many apps as you want in AM, without asking my permission.

I invite you to visit https://github.com/ivan-hc/am-extras to learn more.

Help message and descriptions of third-party databases

In the footer of the output of am -h its now possible to read descriptions of the single third-party databases
Istantanea_2025-08-08_16-44-59


SAS - Simple AppImage Sandboxing

@Samueru-sama He's been working hard on a POSIX shell rewrite of AISAP, and he's succeeded. Bubblewrap sandboxing will now be possible using another default application: sas

am -i sas

The new sandboxing scripts will detect both aisap and sas in the PATH, allowing you to leverage Bubblewrap sandboxing with an additional tool.

PS: I also invite you to visit his new repository dedicated to Ubuntu and the senseless restrictions applied by Canonical in recent years, at https://github.com/Samueru-sama/fix-ubuntu-nonsense


Among other changes

  • added sanity tests for AM and module updates and for installing scripts from the database
  • the workflow that automatically updates translations now takes into account changes in "main", no longer in "dev"
  • fixed and improved the option -a or about
  • replaced several dependencies with their native shell counterpart
  • reduced curl calls not to overload networking
  • code refactoring and other bug fixes

What's Changed

New Contributors

Full Changelog: 9.8.1...9.8.2

"AM" 9.8.1

03 Jul 13:43
877b626

Choose a tag to compare

Steam Deck / SteamOS support!

SteamOS is configured to prevent the user from accessing /usr/local. "AM" normally uses that directory to install symlinks in $PATH and launchers for the application menu. To solve this issue we have set "AM" to run only in AppMan mode, so that it can install and manage apps locally, and rootless, when osing SteamOS on Steam Deck.

photo by @Utopiah
Image Image
am -l am -h

The INSTALL script has also been updated to support Steam Deck. The "am" link to /opt/am/APP-MANAGER will be placed in the user's HOME directory, in ~/.local/bin, so that it can be used in $PATH, from the command line, along with all other programs.


Other changes

New Contributors

Full Changelog: 9.8...9.8.1