Releases: ivan-hc/AM
"AM" 9.8.2
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

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
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
orabout
- replaced several dependencies with their native shell counterpart
- reduced
curl
calls not to overload networking - code refactoring and other bug fixes
What's Changed
- Adds memoto to x86_64 programs by @RaphaelMartin83 in #1695
- Use shell built-ins for
basename
&dirname
by @fiftydinar in #1700 - Option --launcher, fix icon when the latter is a broken symlink by @ivan-hc in #1707
- Remove "light" buidls from
eden-nightly
by @Samueru-sama in #1708 - Option -f, use "column -t" by default and "awk" as a fallback by @ivan-hc in #1715
- Option -f, show a bit more compact table by @ivan-hc in #1716
- Remove --no-sandbox nonsense in AppImage's templates by @ivan-hc in #1717
- Option -a, code rewrite for better detection of installed apps by @ivan-hc in #1721
- Option -a, detect script names after arguments by @ivan-hc in #1722
- Sandbox: share user fonts by default by @Samueru-sama in #1724
- Add an integrity check on main CLI, modules and lists by @ivan-hc in #1728
- Update database.am - reduce "curl" calls by @ivan-hc in #1729
- Update install.am - add integrity check and refactoring by @ivan-hc in #1730
- Add a dbin-powered template by @ivan-hc in #1731
- Add ghcr_dl.sh (by @Azathothas) by @ivan-hc in #1733
- Add support for ghrc-based scripts by @ivan-hc in #1734
- Update
scrcpy
to more maintained and compatible version by @Samueru-sama in #1738 - Add
sas
integration by @Samueru-sama in #1742 - Add support for new "sas" sandboxing solution by @ivan-hc in #1744
- Add
karbonized
by @kris3713 in #1746 - Update sandboxes.am - set full path to sas/aisap in sandbox script by @ivan-hc in #1748
- Delete appflowy by @ivan-hc in #1749
- Improve known third-party extensions removal by @ivan-hc in #1754
- Add official TickTick appimage by @pricci1 in #1756
- Fix broken install of sas when appman is used by @Samueru-sama in #1757
- Add one "python" / remove all others to push "am-extras" by @ivan-hc in #1758
- "AM" 9.8.2 - a new step in favor of third-party databases by @ivan-hc in #1759
New Contributors
- @RaphaelMartin83 made their first contribution in #1695
- @pricci1 made their first contribution in #1756
Full Changelog: 9.8.1...9.8.2
"AM" 9.8.1
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
![]() |
![]() |
---|---|
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
- Don't install desktop files for CLI AppImages by @fiftydinar in #1618 #1619
- Add lazygit, delta, taskwarrior, vicut by @00sapo in #1625 #1626 #1648 #1676
- Update italian locale / Add strings to translate by @ivan-hc in #1636
- Optimizations with shell builtins by @Samueru-sama in #1639
- Fix main-index point by @emmanuel-ferdman in #1643
- Improved option "about" by @ivan-hc in #1650 #1668
- Update
ppsspp
to upstream releases by @Samueru-sama in #1656 - Remove any AppDir and squashfs-root directories in -c and -i by @ivan-hc in #1663
- Improve option "-f" or "files" by @ivan-hc in #1667 #1669 #1670
- Add gpu-screen-recorder, transmission-qt by @Samueru-sama in #1674 #1677
- Update AM-SAMPLE-AppBundle - fix icons handler by @ivan-hc in #1678
- Update and fix Serbian translation by @fiftydinar in #1680 #1681
- "AM" 9.8.1 - add support for SteamOS by @ivan-hc in #1688
New Contributors
- @emmanuel-ferdman made their first contribution in #1643
Full Changelog: 9.8...9.8.1
"AM" 9.8
Ti "AM" in tutte le lingue del mondo - I "AM" you in all the languages of the world
This title in Italian is a play on words, where "I love you" is said "ti amo", the sentence should be "ti amo in all the languages of the world". But mine is not a declaration of love... on the contrary: "AM" now supports languages other than the classic English you were used to!
Here are four screenshots of AM that performs updates in four different languages
![]() |
![]() |
![]() |
![]() |
---|---|---|---|
Spanish (es) | Czech (cs) | Serbian (sr) | Italian (it) |
From now on, you will be able to download and compile translations for your language with any .po editor (e.g. Poedit).
The source file is source.po, available in the new section "translations" of this repositoy.
All you need to do is add your .po file to this directory of the repository, via a pull request on the "dev" branch:
The workflow will do the rest, including synchronization with the source files, APP-MANAGER (the main AM script), modules and most importantly the creation of the .mo files needed to use the languages in "AM".
NOTE: Submitting the pull request to the "dev" branch is the only way to automatically create the .mo file needed to translate AM/AppMan
New option translate
or --translate
A new option, translate
or --translate
, has also been introduced, it can be used with or without an argument. The input must be a "trusted" language code (e.g. "it" for Italian, "sr" for Serbian). Otherwise, "en" (English) will be set by default.
Likewise, if a language is not available in the database, "en" will be set by default. You will be notified when a new language pack is available for you, simply by updating AM/AppMan (option -s
or sync
or option -u
or update
).
If you want to use English as usual, and by explicit choice, you can run the command
am translate en
or
am translate
without an input.
You can also decide to switch between languages, for example, to switch to Italian from another language, in this way:
am translate it
or
am translate
and write "it".
Use one of the codes available here (see the name of the directories):
A list of reliable codes (even those not yet included in the database, just in case) is available here.
simplescreenrecorder-2025-06-03_13.35.14.mp4
Localization files are saved in $HOME, no root is needed to have and use them, and they are usable by both AM and AppMan
![]() |
![]() |
---|
For more information on translations, click on the link below
https://github.com/ivan-hc/AM/tree/main/translations
My special thanks go to @zen0bit for the idea and the effort put into making this release.
Also here are the languages currently available:
- Czech (cs) by @zen0bit
- Serbian (sr) by @fiftydinar
- Spanish (es) by @xplshn
- Italian (it) by me, @ivan-hc
NOTE: Deutch (de) and Russian (ru) have been generated by AI, so they are subject to possible syntax errors, anyone who is expert in these languages is invited to review the translations... or rewrite them if necessary.
I'm waiting for your pull requests, GRAZIE!
Other changes
- AM users who use AppMan mode or install programs locally from AM will use AM modules instead of creating new ones for AppMan, avoiding duplication. Pure AppMan users will have their own modules as usual.
- added improvements for AM packaging in distributions that include it in their package manager, by @fiftydinar.
- added a message to warn users if their distro maintainer is distributing
wget
as a link towget2
(see Fedora). - added a new template to select and install multiple variants of the same program, and based on this many scripts have been merged (see
mercury
andthorium
) reducing the amount of dedicated scripts. - the update output (option
-u
) is colored (see first four screenshots above, in various languages). - added support for the NO_COLOR variable, allowing users who set it to remove colors from AM output (for example, on systems that require screen readers).
Full Changelog: 9.7.1...9.8
"AM" 9.7.1
Permanently remove notifications, if you want
With this release, you can simply run the existing command
am --disable-notifications
...to permanently remove update notifications, even for apps installed later.
Control of scripts requiring root
Fixed a bug with scripts named "remove", which in "AM" are set to run only with root privileges. By @Samueru-sama
Usage in Fedora Atomic
Added support for Fedora Atomic and distributions where /opt is a link in /var. By @fiftydinar
More AppImages, less portable apps
Started a transition where many standalone portable apps will have their own repository where they can be converted to AppImage packages, without alterations, and to allow isolation, sandboxing, and delta updates via appimageupdatetool
(a big plus, especially for large packages).
Some examples, all the development branches of Blender, UrbanTerror, Telegram... but also Calibre, Floorp and Mullvad.
Among the communities open to this transition, there is portable-linux-apps, which you may already know from our catalog, https://portable-linux-apps.github.io
Rehost/reassembly of old, unmaintained (and badly maintained) AppImages
Some apps hosted on problematic hosting services and others that have poor maintenance (for example, Libreoffice and the AppImages of Firefox and Thunderbird) have been rehosted on github repositories.
AppImage is dying, again! Many upstreams are removing them!
"AM" serves not only as a centralized database, but also as a solution for daily monitoring of hosting services, sites and platforms that produce and distribute AppImage packages, with the intent of preserving their maintenance and adoption by developers. Monitoring is done through cataloging these packages and daily testing via "amcheck".
Unfortunately there is an alarming fact to report: many upstream developers have abandoned the AppImage format or have completely removed their historical builds from their archives, apparently to prevent users from using legacy versions of their apps.
My efforts and those of my collaborators seem to be of no use. The lack of information leads many upstream developers to move all their work to more renowned platforms, such as Flatpak and Snap, which guarantee centralization in an official way.
About AppImages, their unavailability and lack of centralization are their weakness.
I wrote "AM", 5 years ago. "AM" is not the arrival, but the starting point, if you want to continue supporting portable packages.
Probably also due to the low visibility of this project, which offers to provide a centralized solution for all portable apps and AppImages.
I invite you to promote "AM" to make people understand that you don't have to look for AppImages. They are (and will be) here, if you want them!
Contribute to our cause! Help us support AppImage!
New Contributors
- @candrapersada made their first contribution in #1522
- @CODJointOps made their first contribution in #1527
- @coyoteclan made their first contribution in #1544
Full Changelog: 9.7...9.7.1
"AM" 9.7
Endless...
In this new release, support for torsocks
has been removed in favor of proxies!
By default, the one provided by the PkgForge team will be used to update and install apps from this site, but it will be possible to set your own proxy by exporting the ALT_GH
variable (HTTPS domain). In order not to force the proxy, an uncrossable limit of API calls will be granted for installations (10) and updates (5).
For the occasion, it is suggested to install the new fork of appimageupdatetool
provided by the PkgForge team, as an alternative to the original one. The installation script will suggest you to install it by pressing 1 or to choose the original by pressing 2. The choice is yours.
Full Changelog: 9.6.2...9.7
Conclusions
For you who read this... try to hold on to the important things. Nothing is forever, except the regret of not having done enough...
If there is something I always have cared about, it is honesty, and what I do not lack is the desire to do things well, and the ever-increasing anger when I see things not going as they should.
After all, we all grew up with different stories, developing different characters and nuances... we are children of what we have learned.
I, personally, owe the desire to do things and the possibility of doing them to a single great person, who taught me to be humble. An honest, sociable person, loved by everyone... especially by me. A person with whom I spent most of my time and who now more than ever I miss, and I know I will miss him in the future.
A person, who I still struggle to believe I will never see again, since that damned April 7th in which, unexpectedly, he left an unfillable void in my life, and in that of my family.
That man was my father.
Ciao papà, ti voglio bene
Nothing will be the same again now that you are no longer here.
"AM" 9.6.2
Various improvements
Since "AM" is a modular program, modules can receive updates separately, independently of changes in the main CLI "APP-MANAGER"... which is why three-digit releases can bring with them much more news than two- or one-digit ones, and vice versa.
This three-digit release brings with it the following.
New option -HC
(or -CH
if you prefer)
This new option is nothing more than the combination of the options -H
/--home
and -C
/--config
, useful to set dedicated $HOME and $XDG_CONFIG_HOME directories for one or more AppImages, this time in one go.
You will need to run
am -HC {PROGRAM}
instead of
am -H {PROGRAM} && am -C {PROGRAM}
...and of course you can use multiple arguments at once.
DISCLAIMER: AppImage dotfile isolation works in most cases, but it all depends on the default settings wanted by the upstream developer/packager. Please use --sandbox
to ensure dotfile isolation, as well as improve security.
In this sense, the above-mentioned -C
and -H
options have been moved from the sandboxes.am module to the management.am module, and the former will be completely dedicated to actual sandboxing via Aisap and BubbleWrap.
"Limited" Type 1 AppImage support
Installation scripts for obsolete, optionless Type 1 AppImages have all been removed. However, they will still be manageable using the --launcher
option.
"AM" discourages the use of Type 1 AppImage packages and encourages users to contact upstream developers to upgrade to a more recent and widely supported runtime, for security reasons.
Typically, Type 1 AppImages are the kind of files that, once downloaded, cannot be extracted using --appimage-extract
nor respond to the other options commonly found on most Type 2 AppImages (both the older ones that depend on libfuse2 and the newer ones that don't)... and instead, the program is launched directly.
That's why I preferred to remove that type of AppImage.
Anyway, if you really rely on an old type 1 AppImage of 2018 or older, install 7z
and manage it with --launcher
as I said above.
Workflows
Scripts are now tested at 250 at a time every hour, every day, to ensure control and review of the applications that can be installed from the "AM" database.
While the workflow is currently disabled in this repository, it is still active in our test repository maintained by @zen0bit
See https://github.com/ivan-hc/amcheck/actions/workflows/test-apps.yml for all results.
Option apikey
Fixed an issue with updating outdated ghapikeys, by @nazdridoy
Options -l
/list
and -q
/query
, new --portable
flag
It is now possible to list and search for only portable apps (not AppImages) in the "AM" database using the --portable
flag
Options -o
/overwrite
and -b
/backup
Both backup/restore options and other options of the same type that use selection can be undone by pressing ZERO, no undo with CTRL+C is needed.
Options -a
/about
and -f
/files
Apps outside of supported databases, i.e. AppImages installed with the -e
or extra
option, can now be referenced as being from the extra
database (which does not exist) in -f
, just like programs installed from supported third-party databases.
Conclusions
I know that bombarding a release with information like this is difficult and may seem confusing (especially for some sites that specialize in reporting releases and that, in an attempt to rework a text with AI, write something completely different from what I wrote here... in fact, unlike Agent Smith in the Matrix, I say "never let a machine do a human's job")... but I have my logic on how releases should be. They should describe real changes... and they should not be aimed at attracting attention and visibility by pushing your project to the top of search results with every commit... just to appear high in a site or catalog (like Flathub, for example).
I prefer that each release is like an updated "guide" to what changes in my project. Users need to know what I did and what has changed. So much so that even my AppMan repository has a link connected to this release, to every AppMan release (and probably you who are reading this came from there too).
Today some developers prefer to attract attention instead of focusing on how to improve their project to consequently supporting an ecosystem by externalizing its dormant potential. Well, I prefer to be boring, and reveal to the people that AppImages evolve and that they have internal options capable of isolating dotfiles while keeping the system clean... or that they support delta updates... that they can be closed in a sandbox or that they can be converted so as not to depend on libfuse2!
This is how you support an ecosystem: revealing its best, and involving the community to improve it!
There are those who work to support a community idea... and those who work for themselves (begging for donations), causing only damage to that community... pushing users towards another community, even if unconsciously.
I took AppImage as something to save, and there are those who have followed my idea by setting up interesting projects supported by entire communities. But as expected, there are always some leeches ready to make all this fail, disguising their project as something extremely useful (while not proposing anything new, but using "trendy" tools that create nice apps... and that's it), but which in fact belongs to a mainstream ecosystem opposite to the one we support as a community.
We who truly love AppImage, want to warn you about false idols: Beware of appearances!
If you really want to support AppImages and those who work to improve them... do it properly! Support all those projects that work directly on AppImage packages! Support whoever builds your favorite AppImage packages! It doesn't matter how (donations, bug reports, pull requests...)... as long as it's directly with those who really understand AppImages.
It's the only way to keep this ecosystem alive.
Many people believe that all AppImages still depend on the old and obsolete libfuse2, and some developers mask their inability to package AppImages by saying "it's hard to make them" but ignoring those who offer to help them, or by saying that "most AppImages are Electron-based applications", when a quick look through my repositories shows that VLC, GIMP, Bottles, VirtualBox, OBS Studio... are anything but Electron apps. Here, be wary of these clichés and of those who tell you these phrases... especially those who elevate their solutions as "definitive" by inventing excuses, lies and cowardly supporting their theses for vile money!
AppImage is many things. Let's support its ecosystem! For real!
What's Changed
- Delete programs/x86_64/unified-communications / Update emacs* by @ivan-hc in #1403
- Delete programs/x86_64/dragoman by @ivan-hc in #1404
- Dev by @ivan-hc in #1405
- Dev by @ivan-hc in #1406
- CI: cache dependencies by @zen0bit in #1407
- Remove obsolete AppImages / fix some broken scripts by @ivan-hc in #1408
- Delete programs/x86_64/ryujinx-mirror by @ivan-hc in #1409
- Delete programs/x86_64/shell-assistant by @ivan-hc in #1410
- CI update by @zen0bit in #1411
- Option "reinstall", add flag "--all" to reinstall everything by @ivan-hc in #1414
- fix: broken ghapikey validation by @nazdridoy in #1416
- Dev by @ivan-hc in #1417
- Update APP-MANAGER by @ivan-hc in #1418
- Update appimage-lister-uniq.sh - create also lists of portable apps by @ivan-hc in #1419
- Add --portable flag in "-q" or "query" and "-l" or "list" by @ivan-hc in #1420
- Use a common versions list for all apps from non-standard sites by @ivan-hc in #1422
- Delete programs/x86_64/revealed by @ivan-hc in #1424
- Dev by @ivan-hc in #1425
- Add citron nightly by @Samueru-sama in #1426
- AM-SAMPLE-AppBundle: Handle AppBundles without a PNG icon by @xplshn in #1434
- Delete programs/x86_64/qtmips by @ivan-hc in #1435
- Dev by @ivan-hc in #1436
- fix(APP-MANAGER): Use _clean_all_tmp_directories_from_appspath by @albertonoys in #1437
- Use magic bytes to detect AppImages/Runimages by @ivan-hc in #1438
- Update maintainer for ghostty by @psadi in #1439
- Update appimagetool and appimageupdatetool by @ivan-hc in #1440
- Update management.am by @ivan-hc in #1441
- "AM" 9.6.2 by @ivan-hc in https://github....
"AM" 9.6.1
Various improvements related to the management of applications external to the "AM" database
This release fixes some issues related to the management of apps installed via the -e
or extra
option, and removes some variables specific to third-party databases delegating them to a file to be used as a source.
Let's proceed in order.
-e
or extra
option
From this release onwards, AppImages installed with this option will have their own category in -f
or files
...
...if there is a duplicate, it will be reported in -a
or about
...
...also, the problems of reporting changed scripts in -s
or sync
and the problems of their removal in the brand new reinstall
option (see https://github.com/ivan-hc/AM/releases/tag/9.6) have been fixed
simplescreenrecorder-2025-03-14_10.51.06.mp4
...all these issues have been fixed by adding an .extra
extension to locally hidden scripts, relating AppImages installed via the -e
option to those programs installed from external databases (for example soarpkg
/toolpack
).
The only difference is that for applications with the extension .extra
there is no description...
...which is fair, since they are not "classified".
A "banner" for -e
in your repository?
I added a small paragraph to the README in which I suggest users who have their own AppImage package not listed in "AM" and who would like to help users get all the benefits (updating, integration, sandboxing...) enjoyed by those listed here
To install and update my AppImage using "AM", simply run the following command:
am -e https://github.com/user/project appname keyword
if you want to install and update it locally, run
am -e --user https://github.com/user/project appname keyword
...or if you use AppMan
appman -e https://github.com/user/project appname keyword
...the idea came to me after I came across a similar instruction in another repository.
It could be an idea for all those who, for one reason or another, cannot or do not want to submit their AppImage hosted on github in the "AM" database.
External databases
I moved all the supported databases into this file that I named "am-extras", like the repository that hosts it:
https://github.com/ivan-hc/am-extras/blob/main/am-extras
The file will be placed in $HOME/.local/share/AM together with the lists.
The new variable $AM_EXTRA_SOURCES
is exportable! You can attach it to the .bashrc file in case you want to use a different list.
"Test-100" Workflow
As the days go by, I'm improving the workflow provided by @zen0bit , so that I can constantly keep an eye on existing scripts, ensuring their highest quality.
You can also keep an eye on those flows, here
https://github.com/ivan-hc/AM/actions/workflows/test-apps.yml
For now, each new test starts automatically every two hours, thus completing all tests in less than two days (also ensuring that I have enough time to fix broken scripts... and do other things).
Mass update of AppImage scripts
All AppImage scripts are now fairly uniform.
All include support for appimageupdatetool
, while zsync
support has been removed as it is not always reliable.
In addition, many scripts have been improved, eventually making them more similar, making them easier to debug.
Repology.org
Yesterday, the repology.org site that about sixty installation scripts rely on, had problems, many workflows (see above) were abruptly interrupted.
While waiting to further resolve the dependency on repology.org, I moved all references to an alternative API kindly provided by the amazing Package Forge team, at https://github.com/pkgforge
The change has been applied:
- to about 60 applications
- to the "install.am" module (the new API has no geographical restrictions, so the
torsocks
patch has been completely removed) - to the "template.am" module
Bug in the -t
option
A nasty bug in the -t
option that led to the creation of a wrong AM-updater if an AppImage was hosted on a site other than github has finally been fixed.
The bug was introduced months ago, with the addition of appimageupdatetool
in the AppImage template. This change made the script longer, which resulted in the command being placed on the wrong line.
Fortunately, not too many AppImages had been added since then... we had already added a ton of them since then, and most of the new ones had the "$version" variable above that line... so it was a problem with 5-6 scripts.
It wasn't a major bug, fortunately, but it did prevent apps from updating.
Just run am reinstall
if you haven't already.
What's Changed
- Add appimageupdatetool to my AppImages by @ivan-hc in #1390
- Add appimageupdatetool support / remove zsync by @ivan-hc in #1394
- Add appimageupdatetool support / remove zsync (pt2) by @ivan-hc in #1395
- Add appimageupdatetool support and remove zsync (i686) by @ivan-hc in #1397
- Update some installation scripts for aarch64 by @ivan-hc in #1398
- Check the connection during installation by @zen0bit in #1399
- Replace repology.org with api.rl.pkgforge.dev by @ivan-hc in #1401
Full Changelog: 9.6...9.6.1
"AM" 9.6
New option to reinstall the apps!
To introduce the new changes, here is a premise on how the AM-updater script works.
Premise
As you well know, portable apps (not only AppImages) hosted on various official and non-official sites, can have different methods to be downloaded and installed.
The diversity of these sites and download methods involves constant maintenance of existing scripts, as many links can disappear for reasons ranging from the removal of a repository by the developer to the removal of a domain.
The scripts are tested automatically (or manually) 100 at a time through our workflows, see https://github.com/ivan-hc/AM/actions/workflows/test-apps.yml
When one of these scripts fails, manual control is triggered, where I go to investigate the causes of such failure... until this script is modified to fix the problem.
This means that the scripts already installed prior to this change, lack new features or even just new online references to be updated.
To suppress this problem, running the command am -s
(to update AM, modules and check for changes in scripts) or am -u
(which includes am -s
and updating all installed apps) will notify you if the online scripts have changed, so you can be warned that you may need to remove and reinstall the application.
If you used to have to run am -R {PROGRAM} && am -i {PROGRAM}
manually on all reported scripts... now it's easier!
New reinstall
option
With the following command
am reinstall
or if you use AppMan
appman reinstall
the scripts will be checked one by one as in -s
, but will also be removed and reinstalled the apps that require such an update.
In this test I installed lxtask
and platform-tools
system-wide, while brave-appimage
, firefox-appimage
and anydesk
are installed locally, per AppMan
I will do a test without modifying any scripts, then I will simulate a change in the scripts by adding some lines in the local scripts... here's what happens
simplescreenrecorder-2025-03-09_16.43.07.mp4
...the 5 apps were removed and reinstalled one by one, respecting the installation level, be it system or local.
NOTE, the simple -i
is executed using the local script name as argument, to avoid installing the wrong counterpart. In case you have set a .home (option -H
) or .config (option -C
) directory or in case you have set a sandbox (option --sandbox
) you will have to do it again using the dedicated options later.
How to check when to use the command?
An app installed with an old script is in the worst case broken (in the sense that the wrong file is downloaded, see #1364) or not updatable.
To know when to use this command, simply start an update with -u
or a sync with -s
. I also added a final message as a reminder, in case you forget the new command (I'll do a simulation in this video too)
simplescreenrecorder-2025-03-09_20.58.19.mp4
Why not add the command directly in -s
?
For transparency. The user needs to know when the script was changed and what was changed, before proceeding with the installation. He can then decide whether to install or remove the application altogether. I don't do things without your consent... I'm not Mozilla (the new terms of service which they say will be applied "at any time" are the reason why I abandoned Firefox after 20 years of use... I moved to a fork).
Among other changes
- references to third-party databases have been further reduced, they can now be safely exported to a variable
- various improvements to third-party database support
- removal, addition and correction of various database applications
New Contributors
Full Changelog: 9.5...9.6
"AM" 9.5
Improved support and extensibility with third-party databases
Third-party database support has never been so extensive, free and secure!
![]() |
![]() |
---|
Read to the end, you'll see some great things!
-i
or install
It will now be possible to install multiple applications "per family" from supported external databases (in the example, SoarPKGS (ex Toolpacks):
simplescreenrecorder-2025-02-21_02.29.24.mp4
...a security check has also been added to check whether applications are actually available online
flags and extensions
Each third-party database will have its own dedicated flag and list.
The flag is unique for each database, you cannot install applications from different databases if it is in use.
For BASH/ZSH/FISH completion, program names with and without extension are available
-a
or about
If applications are detected from third-party databases but not installed, it will notify that an extension is needed. On the contrary, for those installed the info will report the need for an extension to see the details. All details:
The variants and their number will also be listed, as well as details on the installed binary.
-l
or list
The usage of the flag or the extension is suggested in the description of the app in -l
-q
or query
Third-party flags have been removed from -q
, but can be used as a keyword after the --all
flag. A hint has also been added in case there are no search results.
EXTENSIVENESS
If you thought that the existing databases were too ingrained, well... you were right.
This release has undergone a deep refactoring that reduces the addition of third-party databases... to just three lines.
Below are the existing ones (from APP-MANAGER):
#################################
# APPBUNDLEHUB
#################################
export appbundle_repo="https://github.com/xplshn/AppBundleHUB"
#export appbundle_readme="https://raw.githubusercontent.com/xplshn/dbin-metadata/master/misc/cmd/AM-support/AM.txt"
#[ -n "$appbundle_readme" ] && third_party_flags="$third_party_flags --appbundle"
#################################
# TOOLPACKS/SOARPKGS
#################################
export toolpack_repo="https://github.com/pkgforge/soarpkgs (ex toolpacks)"
export toolpack_readme="https://raw.githubusercontent.com/ivan-hc/am-extras/main/soarpkgs-toolpacks/${ARCH}.md"
[ -n "$toolpack_readme" ] && third_party_flags="$third_party_flags --toolpack"
export toolpack_missing_file_msg="\nIt appears that the selected file is not available.\n\nThis happens due to pkgforge's mirror Issue.\nLearn more: https://docs.pkgforge.dev/repositories/bincache/cache\n\nAlternatively, install \"soar\" or \"dbin\" and use those.\n\n"
#################################
# ALL THE ABOVE
#################################
third_party_lists="appbundle toolpack"
It is enough to set $yourflagname_repo
, $yourflagname_readme
and then add a flag in $third_party_flags
As you can see from the code and while I write, AppBundleHUB is currently down, as it is undergoing maintenance... it will be up as soon as the list is restored.
To ensure the security and up-to-dateness of the lists, they will be published at https://github.com/ivan-hc/am-extras
In the modules you will not find functions dedicated to Toolpacks or AppbundleHUB (for the latter only the checks for "AppBundle" as a packaging format are left, to have a dedicated installation script)... but you will find all the functions and references related to third-party flags and extensions concentrated in one place, and without ever mentioning the third-party database.
Example, option -h
or help
Here's how easy it is to add a new flag or extension to AM, this is what will happen to AppBundleHUB when it's ready:
simplescreenrecorder-2025-02-21_03.52.25.mp4
To AppBundle users
Already installed apps will show up as coming from Toolpacks, due to the old identification method.
New installations will have their own flag and list.
The same will be true for all future third-party databases that may be added in the future.
Conclusions
With the renewed support for Toolpacks, the available applications have almost doubled, especially now that they are available in groups of families.
I invite you to also take a look at the following package managers, without whose developers, such a quantity of software would not be possible:
- DBIN https://github.com/xplshn/dbin
- SOAR https://github.com/pkgforge/soarpkgs
...I hope you like this release!
What's Changed
Full Changelog: 9.4.4...9.5
"AM" 9.4.4
Hide installed apps
Do you have any installed applications that you would rather keep the version so much that you don't even want to list them in -f
? Do you want to hide any installed applications from the reach of "AM"/"AppMan"?
This release brings with it two new options:
hide
, to prevent your CLI from seeing, listing, updating and managing the selected appsunhide
, to reversehide
In this video I will hide two system-wide installed apps and two locally installed apps
simplescreenrecorder-2025-02-14_09.14.17.mp4
This can also help if you have a lot of fixed version apps (in my case baobab-gtk3
and system-monitor-gtk3
) and you want to limit updating them, calling github APIs unnecessarily.
There is already a lock
option for this, yes, but if you don't need to list them, you can hide them now.
When you use the command
am hide $APP1 $APP2 $APP3
the remove
script is renamed to remove.old
, thus preventing the installed app from being identified as belonging to "AM"/"AppMan" and effectively making it a "system" or "independent" app.
You can however update it manually by running the related AM-updater
script (if it exists) and remove it manually by running the remove.old
script.
It has its uses, you may need to hide an application from view sometimes.
What's Changed
- Improve Test random 💯 by @zen0bit in #1326 #1329 #1330
- Remove workaround in
nolibfuse
since the appimagetool PR was merged by @Samueru-sama in #1335 - Update management.am, option "
nolibfuse
", if the command "appimagetool
" exists, don't download the Appimage again, by @ivan-hc in #1338 - gittyup: Add version 1.4.0 by @FlawlessCasual17 in #1339
- Update & rename gnome-system-monitor3 to system-monitor-gtk3 by @ivan-hc in #1346
- "AM" 9.4.4 - Add options "hide" and "unhide" by @ivan-hc in #1347
New Contributors
- @FlawlessCasual17 made their first contribution in #1339
Full Changelog: 9.4.3...9.4.4