Releases: ivan-hc/AM
"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 keywordif 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
torsockspatch 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
Contributors
Assets 3
"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
Contributors
Assets 3
"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
Contributors
Assets 3
"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
nolibfusesince 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
Contributors
Assets 3
"AM" 9.4.3
Fix TOR usage where it was prevented
This release allows the end user to verify if app updates from github.com were actually successful, given the API limitations.
During the update, a green message will remind you that you need to restart the TOR service
...on classic GNU/Linux distros with systemd run sudo systemctl restart tor.service to fix the issue.
Use of torsocks with appimageupdatetool
Another issue has been fixed, regarding the coexistence between torsocks and appimageupdatetool. The configuration file for Torsocks will be copied locally and configured on the fly to be used during the process, before being removed.
For more details, see AppImageCommunity/AppImageUpdate#244
Among other changes
- fixed some bugs in database.am module
- improved speed of
-land-qoptions - option
-agained processing time - expanded text margins in
-l,-qand-a
 |
 |
|---|
Website
Icons on pages now load "lazily", allowing for faster and more painless navigation.
To try it out https://portable-linux-apps.github.io/apps
What's Changed
Full Changelog: 9.4.2...9.4.3
"AM" 9.4.2
Add support for FISH-shell autocompletion
First major release of 2025, after exactly one month from the previous one.
As title says, BASH completion has been extended not only to ZSH, but also to FISH. Users of the latter will be able to benefit from it through the appropriate file automatically created in the ~/.config/fish directory.
See #1300 for more.
Among other changes
-foption, versions locked with thelockoption will have a 🔒 next to the version number- added a
-fioption to show only installed apps and not also those integrated with--launcher(already shown in the normal-f) - added an automated action system in github actions to keep in sync the AppImages lists with the apps lists and to check for problematic scripts, so the review is now weekly if not daily, to ensure the correct functioning of the scripts needed to install the applications. Thanks @zen0bit
- securing third-party databases support, in case of any errors
Full Changelog: 9.4.1...9.4.2
Contributors
Assets 3
"AM" 9.4.1
Customize/change the database by exporting variables
One thing I care a lot about is continuity, and as I have seen over the years, not all open source developers are able to maintain a project. This could happen to me in the future. I don't want it to be that way.
Because of this, I have made some essential variables "customizable":
APPSDB, i.e. the "raw" directory of the architecture in use, containing the installation scripts (default value https://raw.githubusercontent.com/ivan-hc/AM/main/programs/$ARCH), this is mainly used in-i,-dand-s/-uAPPSDBLIST, i.e. the list of applications available for that architecture (default value https://raw.githubusercontent.com/ivan-hc/AM/main/programs/$ARCH-apps), this is used every time lists are updated, for example in-l,-qand-s/-uAPPIMAGES_LIST, i.e. the list of AppImages available in the database (default value https://raw.githubusercontent.com/Portable-Linux-Apps/Portable-Linux-Apps.github.io/main/x86_64-appimages), used in-iaand-l/-qwith the--appimagesflagAMCATALOGUEMARKDOWNS, i.e. the pages in .md format from the catalog of applications available in this database (default value https://portable-linux-apps.github.io/apps, add an appname with extension .md to see the content of one file), this is used in-aAMCATALOGUEICONS, i.e. the icons in .png format available in the catalog of applications available in this database (default value https://portable-linux-apps.github.io/icons, add an appname with extension .png to see one file), this is used in-i, in case the installation script fails to get an icon for the applicationAMSYNC, if set to "1" prevents AM from updating itself and updating modules when running-sor-u
it is enough to export the variables above and respect the destination file format (follow the URLs in parentheses) in case you decide to open a new community-driven database that can make up for the lack of support in this repository.
Motivation
I did this to not tie users to this database and to allow them to use AM and all its features if I, Ivan, am unable to intervene for any reason.
There are many discontinuous projects. Should this become one too, it will not be obsolete.
PS: consider this my Christmas present
What's Changed
- Add tutorial for BSD, freeBSD and derivative systems by @ivan-hc in #1235 and #1242
- "AM" 9.4.1 by @ivan-hc and @Samueru-sama in #1252
Full Changelog: 9.4...9.4.1
Contributors
Assets 3
"AM" 9.4
Initial support for *BSD
This version of "AM" brings with it a refactoring that allows it to run on freeBSD and derivatives.
Please note that at the moment, "AM" supports the installation of portable applications for GNU/Linux only.
On BSD-based systems, it is necessary to perform the necessary configurations to allow both binary programs and AppImages to be executed, by installing the appropriate Linux compatibility layout.
There are several guides on this subject, the main one is https://docs.freebsd.org/en/books/handbook/linuxemu/
A simplification of the above guide, oriented to the use of debootstrap is also available here. Thanks to it, I was able to run some test AppImages on GhostBSD
 |
 |
 |
|---|---|---|
google-chrome AppImage |
brave AppImage |
lxtask AppImage |
Note that Chromium-based AppImages require the --no-sandbox flag.
All that glitters is not gold
Please note that "AM" is not responsible for the failure of programs, whether they are on Linux or BSD, and that all "AM" does is download and integrate/install programs into the system, taking them from the source.
In fact, this release allows you to use all aspects of "AM" on BSD, but the failure to run programs has nothing to do with "AM".
BSD systems require additional configuration to run programs written for Linux. In my experiments in virtual machines, I can't help but show failures. For example, running "Archimages" (Arch Linux containers inside Appimages) as in the screenshot below, with gimp and bottles
It's just a matter of configuring the right settings, following the guides.
Toolpacks on BSD
Several programs from the Toolpacks database appear to be BSD-compatible, as they are static binaries. To see a list and install them, see the --toolpack flag reference (command am -h for more information).
Future
This release is just an introduction to BSD support. Experts are encouraged to participate in improving this support on "AM".
There are two possible ways:
- add a directory to this database that contains only installation scripts for BSD-compatible programs. You can also select those that work in tests. At the moment, "AM" only has installation scripts for x86_64, aarch64 and i686 architectures on Linux. It would be nice to add another one that works for BSD https://github.com/ivan-hc/AM/tree/main/programs
- add a script that can automate the creation of a compatibility layout for Linux, based on the official guides, so as to allow, in a single command, the addition or removal of this support, a guide is available here https://github.com/ivan-hc/AM/blob/main/docs/guides-and-tutorials/bsd.md
Other changes
lessis now an "optional" dependency (but suggested in-hand-l) by @Samueru-sama- fixed several bugs related to versioning
- removed other basic dependencies, such as
stringsby @Samueru-sama - improved table generation speed in
-fby @Samueru-sama - better versioning for self-updating applications, through permission levels
- ported a good part of the code to POSIX by @Samueru-sama
- new functions to use and switch between
sedon a per-implementation basis (default is GNU) by @Samueru-sama
What's Changed
- Beautify sandbox exit messages by @ivan-hc in #1192
- wrap long lines around by @Samueru-sama in #1193
- Option "-h" or "help", add instructions on how to test scripts downloaded ("-d") or created ("-t"). by @ivan-hc in #1196
- allow setting
$SCRIPTDIRby @Samueru-sama in #1197 - Fix "$SCRIPTDIR" in sistems without XDG_DESKTOP_DIR by @ivan-hc in #1198
- only warn about namespaces check if unshare is present by @Samueru-sama in #1200
- simplify check for
${SUDO,DOAS}_USERby @Samueru-sama in #1202 - improve check for cpu arch by @Samueru-sama in #1203
- improve check for sudo by @Samueru-sama in #1204
- Various fixes between APP-MANAGER, INSTALL and AM-INSTALLER by @ivan-hc in #1205
- "AM" 9.4: support for FreeBSD by @ivan-hc & @Samueru-sama in #1209
Full Changelog: 9.3...9.4
Contributors
Assets 3
"AM" 9.3
Install AppImages and Sandbox them... in one go!
This release allows sandboxing of AppImage packages while installing them via a flag for -i and -ia or a dedicated option.
Option -i or install, with flag --sandbox
The new flag is --sandbox, using it in combination with -i or install allows you to install also AppImage packages from local scripts, if you have created your own and also from your custom database or a third-party repo you use near the "AM" database (see the "AM" documentation for more information)
am -i --sandbox {PROGRAM}
or localy
am -i --user --sandbox {PROGRAM}
appman -i --sandbox {PROGRAM}
Option -ia or install-appimage, with flag --sandbox...
...while in combination with the -ia or install-appimage command it allows you to select and install only the AppImages present in the "AM" database (which as I write, are 2123, see portable-linux-apps.github.io/appimages)
am -ia --sandbox {PROGRAM}
or localy
am -ia --user --sandbox {PROGRAM}
appman -ia --sandbox {PROGRAM}
...and the new variant of -ia: the -ias option!
But to simplify things, you can replace -ia --sandbox with the new option -ias (aka Install AppImage & Sandbox)
am -ias {PROGRAM}
or localy
am -ias --user {PROGRAM}
appman -ias {PROGRAM}
See it in action!
simplescreenrecorder-2024-12-04_16.44.11.mkv.mp4
You will find all the documentation on how sandboxing works in the related guide.
Option --sandbox
As you may have guessed from the video above, from now on, AM users will be able to choose whether to install "Aisap" locally or system-wide.
Of course, make sure you already have an "appman-config" configuration file. If you don't have one, start any installation using the --user flag or start AM in "AppMan Mode" using the option --user. For more information, see am -h.
Option -f or files
The message indicating whether the AppImages are in a sandbox will only be displayed in tables that have the 🔒 symbol
...the aisap command will be checked first, regardless of whether it is present system-wide or locally.
Learn more about "Aisap" https://github.com/mgord9518/aisap
What's Changed
- simplify how to get path to appimage & use shell built in test by @Samueru-sama in #1174 and #1182
- Fix total size, by @Azathothas by @ivan-hc in #1185
- "AM" 9.3, allow enable sandoxing when installing AppImages by @ivan-hc in #1180
Full Changelog: 9.2...9.3
Contributors
Assets 3
"AM" 9.2
Update and list portable AppImages scattered in your system!
This release introduces support for AppImage packages integrated with the --launcher option, and allows listing them with the -f option... but let's proceed in order.
Option -f or files
From today, AppImage packages integrated with the --launcher option will be visible in the list
They will be listed with the file name (in the screenshot above I renamed my AppImage of the game "0AD" (available at https://github.com/0ad-matters/0ad-appimage) to 0ad. The file path and its size are also shown.
The detection is done on the fly, so if, like me, you have an AppImage on an external partition that is not mounted, the size will not be calculated, and -f will detect that the path is not accessible.
I advise you to give a nice name to your AppImage... or you will end up like this
But that's not all I'm saying... what if you were to upgrade to a later version? The file name would still be the same, even though it's updated.
And speaking of updates... I know that's what you're here for, right? See below.
Option -u or update and option/flag --launcher
Added support for appimageupdatetool, which allows updating AppImage packages that include the information needed to update themselves via binary deltas.
Since people who normally use --launcher or AppImageLauncher or GearLever... or none of these tools except for the sole purpose of integrating them into the application menu... tend to keep multiple versions of an application... I thought it was not the case to integrate it directly into -u, so you can do it optionally
am -u --launcher
or
am --launcher -u
instead of -u you can use update... it depends on what suits you.
It is important that you install appimageupdatetool for this option to work.
simplescreenrecorder-2024-12-01_08.36.22.mkv.mp4
NOTE, I remind you that about 10% of AppImages support delta updates, so if you want to be sure to always have the latest version of all AppImages, rely on the installation options -ia or install-appimage and -e or extra... in addition to -i or install, which is for all portable programs, not just AppImages.
Various fixes
- the installation process checks if there is a "dead" symlink in $HOME/.local/bin with the same name as the topic you are installing, and removes it (since classic installations have the priority over
--launcher) - the detection of "dead" symlinks is more detailed and repetitive, and takes into account whether it is actually the case to remove them
- obsolete launchers and symlinks are re-detected both while running
-cand with-fand-u...and with--launcheritself, while you start it... so you have more opportunities to clean them - the
--launcheroption detects if a dead symlink or a command in $HOME/.local/bin already exists, and asks you if you want to overwrite it - the "install.am" installation module has been revamped, preparing for new features planned for the next months
- the
-uoption has undergone a more thorough code cleanup and precise, new BASH functions have been added to improve interaction, depending on the commands in use - the messages of end of installation or end of update are also visible if no app as been installed or only apps have been updated (command
am -u --apps) - many commands have been converted to POSIX
Conclusions
The --launcher option is a niche option, that I wrote inspired by any traditional AppImage package manager... and that I ended up using with really large packages that need to be kept on a dedicated partition.
Introducing this feature made me realize that AM can always go further. It all started with an issue, and in less than 24 hours this release came out. I wouldn't have expected it, at this time... if someone hadn't suggested it to me.
I'll continue to use AM as I intended, like APT or PacMan. There are options I've created that I like more or less... and I stress "even though I'm the creator"... and --launcher is one of my least favorites, because it reminds me of the early days, when none of the existing solutions satisfied me... but... damn. I really enjoyed working on it today.
What's Changed
- Update install.am, code refactoring by @ivan-hc in #1168
- Convert option "-ia"/"install-appimage" to a function under "-i" by @ivan-hc in #1169
- Update modules by @ivan-hc in #1170
- "AM" 9.2, improve support to local AppImages giving them updates support (appimageupdatetool) and a dedicated table in
-fby @ivan-hc in #1172
Full Changelog: 9.1.3...9.2