Skip to content

Releases: ivan-hc/AM

"AM" 9.8.2

08 Aug 14:28
Compare
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
Compare
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

"AM" 9.8

03 Jun 10:58
6a53099
Compare
Choose a tag to compare

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

es cs sr it
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

Istantanea_2025-06-03_13-38-23 Istantanea_2025-06-03_13-38-10

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:

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 to wget2 (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 and thorium) 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

21 May 07:12
96734d0
Compare
Choose a tag to compare

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

Full Changelog: 9.7...9.7.1

"AM" 9.7

13 Apr 11:18
96e523d
Compare
Choose a tag to compare

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

04 Apr 02:27
19d80c1
Compare
Choose a tag to compare

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}

Istantanea_2025-04-04_02-42-44

...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

Istantanea_2025-04-04_03-43-34


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

Read more

"AM" 9.6.1

14 Mar 12:58
d1f3dd0
Compare
Choose a tag to compare

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...

Istantanea_2025-03-14_13-16-57

...if there is a duplicate, it will be reported in -a or about...

Istantanea_2025-03-14_13-17-53

...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...

Istantanea_2025-03-14_13-18-37

...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.

See https://github.com/ivan-hc/AM#do-you-own-a-repository-for-appimages-external-to-this-database-follow-these-instructions


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

09 Mar 23:39
619a533
Compare
Choose a tag to compare

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

21 Feb 02:10
0c9b0cc
Compare
Choose a tag to compare

Improved support and extensibility with third-party databases

Third-party database support has never been so extensive, free and secure!

Istantanea_2025-02-21_05-54-46 Istantanea_2025-02-21_02-26-30

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

Istantanea_2025-02-20_04-15-33


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

Istantanea_2025-02-21_02-37-10


-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:

Istantanea_2025-02-21_03-49-04

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

Istantanea_2025-02-21_02-38-06 png


-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.

Istantanea_2025-02-21_02-45-25

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:

...I hope you like this release!

What's Changed

  • "AM" 9.5 - Rewrite of third-party databases support by @ivan-hc in #1358

Full Changelog: 9.4.4...9.5

"AM" 9.4.4

14 Feb 11:00
afc3d06
Compare
Choose a tag to compare

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 apps
  • unhide, to reverse hide

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