"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

• less is now an "optional" dependency (but suggested in -h and -l) by @Samueru-sama
• fixed several bugs related to versioning
• removed other basic dependencies, such as strings by @Samueru-sama
• improved table generation speed in -f by @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 sed on 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 $SCRIPTDIR by @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}_USER by @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

"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

"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 -c and with -f and -u...and with --launcher itself, while you start it... so you have more opportunities to clean them
• the --launcher option 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 -u option 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 -f by @ivan-hc in #1172

Full Changelog: 9.1.3...9.2

"AM" 9.1.3

Full support for AppBundles from AppBundleHUB

This release sees the addition of a new database of third-party applications to the "AM" database: AppBundleHUB, and more precisely the programs in AppBundle format (see https://github.com/xplshn/pelf).

---

Programs in lists

Programs in lists will be listed with the extension ".dwfs.appbundle". For example, "ristretto.dwfs.appbundle" or "chromium-web-browser.dwfs.appbundle"

---

Option -l or list

As an exception, the list will be accessible using the existing --toolpack and --all flags. Here is the output with the --toolpack flag

...this is the only case where you will need to use a flag.

Since the list is still small, I preferred to merge them into a single list. The programs in AppBundle format (so with the extension ".dwfs.appbundle") will all come from AppBundleHUB.

---

Option -q or query

Unlike -l, programs in AppBundle format will be searchable normally (i.e. without flags) with the -q option, therefore alongside the applications in the "AM" database

...note the programs with the extension ".dwfs.appbundle", this will serve to distinguish them from those in the "AM" database.

---

Completion

The reason for adding these extensions is not only to distinguish them, but also to quickly list them using BASH/ZSH completion

simplescreenrecorder-2024-11-27_18.36.09.mkv.mp4

...you won't have to work too hard to distinguish them from the lists.

The listing is the only reason they have the extension... but the installation is a different thing. See the next paragraph.

---

-i or install option

No flag is needed, AppBundles will be installed only if followed by the extension ".dwfs.appbundle", and they will be installed WITHOUT EXTENSION

...and yes, the information in -a will also be reported in more detail. See next paragraph.

---

-a or about option

AppBundles will have the privilege to also show the "real" package name, whether they are installed or not

As with Toolpacks, apps from AppBundleHUB will see pages created on the fly, using the list provided by the owner of that database. Thanks @xplshn

A small aside, the -a option in general has also undergone major structural changes. Now the information will be displayed in a clearer and more pleasant way... assuming that the pages in use are up to date (I'm talking about the "AM" database, I need a hand with my catalog).

---

Option -f or files

Of course, the list of installed apps will also show that the apps come from a different database ("DB" column) and a new file type called "dwarfs-appbundle"

For those who don't know, AppBundles are POSIX scripts compressed with "DWARFS" and that contain the entire application. With a powerful enough text reader, you can read their content. They literally represent the statement "one application = one file".

To learn more about this topic, I invite you to visit the "Pelf" repository, at https://github.com/xplshn/pelf , a tool that can create this fantastic packaging format.

---

Conclusions

Portable programs are always welcome in "AM", no matter how many formats they are. As long as there is "AM" to distribute them, you will have no reason to complain about too many packaging formats.

Flatpak only supports .flatpak, Snap only supports .snap, APT only supports .deb... etc. etc.

"AM" is more inclusive. It accepts these diversities that are not tied to a package manager. An AUR helper does the same thing, but only for Arch Linux. Here instead we want to allow all GNU/Linux distributions to use the same programs according to their efficiency.

What does AppBundle have more than others? I know that it also works on Musl distributions, while many programs, and probably most of them... are written to work with GLIBC. And if you are an AppImage user, how many times have you tried to start a program that is not compatible with your version of GLIBC? Many of you will have surely received this type of error in the past.

Don't get me wrong, I love AppImages. I have 70 of them in my repositories.

With Archimages and similar I have tried to use Arch Linux containers inside AppImages, to provide recent programs that also work on old Linux systems, and precisely because they are portable containers. AppImage is also solving a lot of problems recently, and I invite you again to follow its developments, they are doing fantastic things recently. AppBundle instead was born already like this. It is still not very popular, but I firmly believe that it, like many other emerging realities, deserves due attention.

Let's give everyone a chance.

The beauty of Linux is precisely this: diversity!

---

What's Changed

• Added Programs by @Sush-ruta in #1153
• Add NixAppImage support by @ivan-hc in #1154
• update the ryujinx situation by @Samueru-sama in #1155
• add cromite by @Samueru-sama in #1158
• "AM" 9.1.3, full support for AppBundleHUB by @ivan-hc in #1160

Full Changelog: 9.1.2...9.1.3

"AM" 9.1.2

"Transparent" updates

For aesthetics, the output of the update process for applications is hidden and runs in the background... but from this release it is possible to extend the am -u command using the "--debug" flag, which will ensure that the messages are displayed.

USAGE

            am -u
            am -u --apps
            am -u --debug
            am -u --apps --debug
            am -u {PROGRAM}
            am -u --debug {PROGRAM}

The new --debug flag can then be used to update individual apps, just apps, or updating everything

simplescreenrecorder-2024-11-20_13.33.15.mkv.mp4

...you will be able to see how the applications are updated, and you will notice different systems, depending on the application installed.

Here is an example with appimageupdatetool installed, even though it has the same apps as the previous video

simplescreenrecorder-2024-11-20_07.28.34.mkv.mp4

As you may notice, the messages change, as some applications have update scripts that support multiple update standards, and which can override each other depending on the situation (for example, if the metadata is not present in the application, the classic version comparison update will be performed).

With this release, updates are no longer mysterious!

NOTE, Topgrade users will get the regular output as usual, without flags.

---

Among other changes

• -c option, improved cleaning of installed items via the --launcher option
• --launcher option, now applies the method used in the installation scripts to integrate launchers and icons from the AppImages you have scattered in the system, thanks @Samueru-sama for the tip
• fixed a bug in the -t option, where, having a Github key, if you created the installation scripts, it was written in the script, thanks @nazdridoy for reporting this

What's Changed

• change grep pattern to also recognize uruntime appimages by @Samueru-sama in #1129
• Added PICsimLab - Programmable IC Simulator Laboratory by @nazdridoy in #1135
• Fix e improve --launcher option and related functions by @ivan-hc in #1139
• [AppImage PR] Geeqie by @contrarybaton60 in #1142
• Use BINDIR instead of ~/.local/bin by @ivan-hc in #1143
• Makes --launcher extract icon and launcher like install scripts do by @ivan-hc in #1145
• Simplify function to run the AM-updater by @ivan-hc in #1147
• fix puddletag by @Samueru-sama in #1148
• AM 9.1.2, add flag support to option -u or update by @ivan-hc in #1149

Full Changelog: 9.1.1...9.1.2

"AM" 9.1.1

More and more programs

The -l or list option will show the total number of installable programs in the header!

By default, the am -l command will only show the applications available in the "AM" database, but with the addition of a message that will suggest you to run the command with the --all flag, to show them all, from all supported databases (for now only "AM" and "Toolpacks").

The update speed of the program list from the Toolpacks database has also been improved, reducing it by 3/4 of the time it took in the previous version.

The Toolpack and AppImage list files can now be consulted offline.

---

New step in "synchronization"

Added an additional step during synchronization (option -s or sync) and consequently, at the end of the update (option -u or update) during which the Toolpack and AppImage lists will be created and updated.

simplescreenrecorder-2024-11-13_21.31.23.mkv.mp4

You will be able to view it from the first update you do after getting this release.

---

AppBundle Support

A new template is now available, made by @xplshn , creator of dbin and AppBundle. The new script will better integrate this new portable application format for GNU/Linux.

For more information, go to the repositories of the projects involved:

• https://github.com/xplshn/dbin
• https://github.com/xplshn/pelf
• https://github.com/xplshn/AppBundleHUB

Last but not least... AppImage packages are all from the "AM" database. The Toolpack repository also distributes them, but I decided not to list theirs to avoid duplicating existing apps that have their own dedicated script. I want to list as many unique apps as possible and in different portable formats. And AppBundle or FlatImage (see https://github.com/ruanformigoni/flatimage) are some of the new ones.

---

Terms for BASH/ZSH completion in Toolpack apps

Terminal completion of search terms for programs from the Toolpacks repository will all have the ".toolpack" extension, to improve speed in researching (option -a or about) and especially in installing programs, and without having to resort to the --toolpack flag (option -i or install).

---

Bug Fixes

Fixed several bugs regarding updating (-u or update) and cleaning (-c or clean) on systems with many applications installed, either from the "AM" database or the "Toolpacks" database. See #1109

---

Conclusions

The introduction of Toolpacks support has brought many new features, thousands of more applications (suddenly) and many small details to fix to make "AM" an ever better CLI, to manage all portable programs for GNU/Linux.

I invite you to deepen your knowledge on the new support database, "Toolpacks", at https://github.com/Azathothas/Toolpacks, and I invite you to contribute as much as possible to these projects, parallel, but increasingly part of this project of mine called "AM".

New, very interesting portable formats are emerging, and "AM" wants to be a springboard for these applications.

Also take a look at dbin, by our friend @xplshn , who with this release puts his signature among the contributors to this project.

Thanks to everyone!

What's Changed

• Remove AppImages from Toolpacks list by @ivan-hc in #1100
• feat: Add the AppBundle template by @xplshn in #1102
• Option -i, Toolpacks, add full support for AppBundle apps by @ivan-hc in #1103
• S3Drive by @Twig6943 in #1108
• Strawberry by @Samueru-sama in #1110
• Show total number of programs available in -l... by @ivan-hc in #1113

New Contributors

• @xplshn made their first contribution in #1102
• @Twig6943 made their first contribution in #1108

Full Changelog: 9.1...9.1.1

"AM" 9.1

Unity is strength!

This release sees the addition of support for programs from a third-party repository, which DOUBLES the number of installable programs!

I'm talking about "Toolpacks" https://github.com/Azathothas/Toolpacks

To show you how the number of applications grows, I added to -l or list the ability to see the total apps available in each database, or overall... when you exit the list.

But let's proceed in order. Here's how the functioning of "AM" changes thanks to "Toolpacks".

---

The --toolpack flag

The new --toolpack flag will be usable in the -i (installs), -l (lists) and -q (searches) options. Here is how the syntax should look like.

            am -i --toolpack {PROGRAM}
            am -i --toolpack --user {PROGRAM}
            am -l --toolpack
            am -q --toolpack {KEYWORD}

...you can see more details by starting the help message with the command am -h.

---

Install applications

You can install programs from the Toolpack repository by adding the --toolpack flag, this way items from that repository will have priority over those available in the "AM" repository

install.mp4

...and not only that, you can also use the .toolpack extension to the program you are interested in, and without using the flag. Here is a short demonstration, locally I will install steam.appimage, which is equivalent to the Steam AppImage (steam package) already present in the "AM" repository... and available as a fallback on Toolpacks, in case of problems with github.com

install.steam.mp4

This is just a demonstration.

Of course, Toolpacks is more oriented to installing static binaries, including AppBundle and Flatimage formats.

For AppImages, regular installation from the "AM" database is recommended!

PS: As you may have noticed from the video, the -a and -f options have also undergone some changes. Let me tell you about them.

---

-f or files option to list installed apps: what's changed?

A new column "DB" (or "database") has been added to the table listing installed programs. From there it will be possible to recognize which programs were installed from the "AM" database (am), which from "Toolpacks" (toolpacks)... and also which were installed from external sources, for example, with the -e or extra (none or unknown) option.

In the future, on request, new databases could be implemented in the same way.

---

Option -a or about

Application installed by Toolpacks will appear with the package name with the extension .toolpack, but installed with the actual program name as listed. No flags are needed here.

about.mp4

...note that the page loading times are slower, this is due to the "on the fly" creation of the page to be displayed, these being not "real" pages like the ones we have in our catalog.

...by the way. And the lists? Here's what happened.

---

-l and -q options, use of new --toolpack and --all flags

The --toolpack flag is not the only one that has been introduced. The -l or list and -q or query options have a new additional flag: --all

As you may have guessed, it allows you to display all the applications present in all the databases, together...

list.mp4

...and to perform searches in them

query.mp4

so the new syntaxes are as follows, for the lists

                am -l
                am -l --all
                am -l --appimages
                am -l --toolpack

...and for the queries

                am -q {KEYWORD}
                am -q --all {KEYWORD}
                am -q --appimages {KEYWORD}
                am -q --pkg {PROGRAM1} {PROGRAM2}
                am -q --toolpacks {KEYWORD}

The flags are pretty intuitive and will tell you what they do.

---

Conclusions

Thanks to the creators of Toolpacks and Dbin for their support. Thanks to all the contributors of the issue that started it all.

I invite you to visit their repositories and everything they have to offer!

Since the applications available in the "AM" database began to exceed a thousand, I have done everything to make my project as extensible as possible, allowing the use of custom repositories (see newrepo option). The fact is that I do not know how long I will have the possibility to continue dedicating myself to this project... so, in my absence, the addition of Toolpacks will contribute to exponentially grow the number of programs available, even in my absence.

Thanks to everyone who wants to support my project! Thanks to everyone!

---

What's Changed

• Add support for Toolpacks by @ivan-hc in #1096

Full Changelog: 9.0.2...9.1

"AM" 9.0.2

Allow to use icon theme immediately after installation

Normally in "AM", an installation would patch the .desktop file to use a well-defined path for icons, i.e. /opt/{PROGRAM}/icons, and then to use an icon theme it was enough to run am --icons {PROGRAM}.

From now on the --icons option can be used as a flag for the -i or install and -ia or install-appimage installation options, like this:

am -i --icons {PROGRAM}

or

am -ia --icons {PROGRAM}

and works with the pre-existing --debug, --force-latest and --user flags.

Changes will only be made to apps installed when the above commands are run.

As in am --icons, icons for other installed apps will be symlinked to ~/.local/share/icons/hicolor/scalable/apps, but launchers will remain intact.

NOTE, if you use the --user flag together with --icons, only local apps will be considered. Use am --user if you also want to use icons of apps installed at system level.

---

PS: this is the second release in thwo hours, please don't miss the other one https://github.com/ivan-hc/AM/releases/tag/9.0.1

"AM" 9.0.1

Shut up! I "AM" updating!

New options to disable/enable notifications when updating apps.

---

--disable-notifications

	am --disable-notifications

Description:

Disable notifications during apps update.

---

--enable-notifications

	am --enable-notifications

Description:

Eable notifications during apps update (nulls "--disable-notifications").

---

All they do is comment/uncomment lines containing notify-send in the AM-updater files of installed apps.

simplescreenrecorder-2024-11-07_13.58.26.mkv.mp4

NOTE, if you really hate notifications, run the command after every install or new apps will not be patched.

NOTE2, apps that use zsync to update will rely on version comparison or appimageupdatetool if installed and supported by the app.

"AM" 9

Install and manage applications both at the system level... and locally!

From now on "AM" will be able to install and manage also local applications, installed with AppMan or... directly installing them from "AM", using the new implementation of the --user option as a "flag" for the pre-existing installation options, namely:

• -i or install, for normal installations;
• -ia or install-appimage, to install only AppImage packages;
• -e or extra, to install AppImage packages from github outside this database.

But let's proceed in order.

---

Install applications locally or at system level

In this video I will first install an app locally, and then one at system level. The root password is asked only in the second case.

install.mkv.mp4

All this whitout switching to "AppMan Mode" or using "AppMan"!

---

The --user flag

The "--user" option can also be used just as a flag for installation options. For example:

• Use it to install applications locally, option "-i" or "install":

   am -i --user {PROGRAM}
  

• Also suboptions of "-i" can work with this flag:

   am -i --user --debug {PROGRAM}
   am -i --user --force-latest {PROGRAM}
   am -i --user --debug --force-latest {PROGRAM}
  

• Same for AppImages only, option "-ia" or "install-appimage":

   am -ia --user {PROGRAM}
   am -ia --user --debug {PROGRAM}
   am -ia --user --force-latest {PROGRAM}
   am -ia --user --debug --force-latest {PROGRAM}
  

• External AppImages can be installed like this as well, option "-e" or "extra":

   am -e --user user/project {APPNAME}
   am -e --user user/project {APPNAME} {KEYWORD}
  

But that's not all that's changed... "AM" 9 or higher is also able to, update and manage apps locally, by default, and without having to switch to "AppMan Mode"!

---

List installed programs

"AM" will list all the apps it can handle both in -f...

files.mkv.mp4

...and in -l...

list.mkv.mp4

...thanks to the configuration file for "AppMan", which, if not existing, will be created the first time you start an app installation locally.

config-file.mkv.mp4

Here is a small demonstration of how the data changes, removing the file.

---

Refresh everything, for real!

But if you think lists are just "fluff"... here's what happens if you refresh with the -u option.

update.mkv.mp4

All locally and system-wide installed apps will be updated!

The mechanism this time involves starting the related AM-installer scripts following the entire file path, and no longer running the script in individual directories.

---

Removing applications

But unlike installations, which are either for local-only or system-only apps... the removal happens all at once!

Here's what happens if I use the am -R command, listing a local app first, then a system app, then a local app again.

remove.mkv.mp4

This is done by determining the permissions in the remove file, which depending on the permission level, is executed to remove the app it belongs to.

---

But how many options have you changed?

This release has seen a major overhaul in most of the options, here is a complete list of all the changed options:

• -a can detect if an app is installed or not in both ways
• -b for backups of apps that may be needed for both AM and AppMan
• -C to create potable .config directories
• -e to install AppImages from github out of this database
• -f to list the installed apps
• -H to create portable .home directories
• -i to install apps
• -ia to install appimages
• -o to restore backups/snapshots created with -b
• -r and -R to remove apps
• -u to update all the apps, modules and "AM" itself
• --icons to get icons from installed apps, to use themes
• lock to lock version and updates
• unlock to undo "lock" (see above)
• nolibfuse to convert old AppImages to the new runtime, without libfuse2 dependence
• --sandbox to sandbox AppImages (but still require the root permissions, for now)
• --disable-sandbox to undo --sandbox (see above)
• --force-latest to downgrade a github app quickly if it is a dev build or an alpha
• --rollback to downgrade the apps from a list
• -c to clean unneeded files and the cache
• -l to list all apps availeble, now shows both local apps and system apps
• -s to check for installation scripts changes among the installed apps in this database, to update modules and "AM" itself, not the apps
• -h (of course) by adding the new info about --user
• --user that now is suggested as a flag instead of using it as an option to swith to AppMan Mode
• -d but just the flag --convert to convert the installation scripts for "AM" to scripts for AppMan... or generally for a local installation

all other options (the few remaining ones) have remained unchanged.

---

Documentation

The README of this repository has been lightened, and has a subdirectory where tutorials and troubleshooting have been divided, creating dedicated pages.

They are accessible simply by scrolling the main page of this repository!

Conclusions

It's been a very intense week. Thanks to everyone who contributed to the tests in the "dev" branch of this repository.

This release is not a reason to break "AppMan", I made sure that the users of the latter do not notice the difference, preserving their user experience.

AppMan will still be maintained, being a portable edition of "AM", even if limited to the use of local apps only... and there are system configurations for which users do not have administrative privileges. "AM" belongs only to those who install it, as always. "AppMan" is even more flexible, in this respect... but now the difference between the two is almost zero.

I hope you all enjoy this release!

Sorry again for the wait... see you next!

---

What's Changed

• Update install.am: fix AppImage list (option -ia) by @ivan-hc in #1043
• Rename ntfy to ntfydesktop by @ivan-hc in #1061
• Update install.am: add Torsocks patch for repology.org by @ivan-hc in #1065
• Update readme (for "AM" 9) by @ivan-hc in #1068
• "AM" 9: handle "AppMan" programs without switching to "AppMan Mode" by @ivan-hc in #1036

New Contributors

• @lwhiteley made their first contribution in #1044

Full Changelog: 8.4.1...9