"AM" 6.10.1

Improved the option "-c" or "clean"

I assume you all know the difference between "AM" and "AppMan".

The other evening I updated my Chromium AppImage, and after installing it with the command appman -i chromium and after isolating it with the command appman -H chromium not to dirty my $HOME directory with its dotfiles (see module "sandboxes.am"), I finally ran the command appman -f to check if the version that appeared was ok, and... I noticed that the installation had reached 200 MB while it should be ust 140 MB instead. The issue here were that the dotfiles had been distributed in the "chromium.home" directory previously created with the option -H, so the ".cache" directory created inside it was filled, making the whole installation of the AppImage look larger than it should.

From this episode I decided to extend the "-c" option also to all the "*.home/.cache" directories near the installed AppImages, if they exist. And I didn't just add this:

• as I've already said above, now this option will clean *.home/.cache directories of AppImages created with the option -H;
• unnecessary operations are hidden if dedicated files and directories are not in place, as was already the case for cleaning of orphan launchers created with the option --launcher;
• all deleted files from the "modules" directory will be listed one by one;
• also, the cleaning process is faster, almost instantaneous.

Here is a test I've done with both "AM" and "AppMan", by adding a .home directory in Chromium (for AppMan) and Avidemux (for "AM") and some random files in the "modules" directory of "AM":

simplescreenrecorder-2024-06-06_16.40.45.mkv.mp4

Full Changelog: 6.10...6.10.1

"AM" 6.10

Password: inclusiveness!

Since the beginning, the rule has always been the same: the user who installed "AM" owns "AM, and with it all the contents of the /opt/am directory. This resulted in constant error messages for other users of the system, whether privileged or not (see this screenshot) because none have "write permissions" in /opt/am other than the owner.

However, we have an "AppMan Mode", which can be activated with the --user option, so... why not suggest to these excluded users to use "AM" as non-privileged users? Like "AppMan" indeed!

This is the point of this release!

The admin that owns "AM" to enable "AppMan Mode" needs to use the option --user, as always, also its the only one that can update the core script APP-MANAGER in both "AppMan Mode" (option --user) and "Normal Mode" (option --system, always suggested during the use).

Users without write permissions in /opt/am will see a prompt (see the screenshot down below), choose Y or N (default is Y).

The following message only appears to the owner of "AM" while for other users, the use of "AM" in "AppMan Mode" will be discounted.

"AM" is running as "AppMan", use am --system to switch it back to "AM"

Obviously, from now on, APP-MANAGER is also read/write only for the owner of "AM", for security reasons.

---

Among other changes:

• fixed versioning in many other applications, adding new checking/creating criteria for -f, -l and other options that use them;
• replaced all references to ".cache" with a single common variable, and functions to make the directory operational and secure;
• added version cleanup/update mechanism for -o option;
• added function to check if an app to be updated is read-only (result of previous attempts on permissions, a series of commits then canceled in favor of this release), useful for future implementations *

* we hope to implement a group in the future whose members can update "AM" and its modules with RW permissions in /opt/am, but for now, the security, updating and oversight of "AM" is in the hands of user who installs/owns it.

What's Changed

• Fix version in the installation scripts "chromium-latest" (the icon too), "inkscape", "inkscape-next" and "nootka" by @ivan-hc in #617
• If version is not in .zsync file, use the last edit date by @ivan-hc in #620
• Replace ".cache" references with the "$AMCACHEDIR" variable / added write control on installed app directories / conversion in functions of the processes to update apps and generate the options list by @ivan-hc in #622
• If "AM" is read-only, suggest using "AppMan Mode" (for multiuser systems) by @ivan-hc in #626

Full Changelog: 6.9...6.10

"AM" 6.9

Reduced the number of modules from 16 to 10

A new module has been added which brings together 4 and therefore includes 8 more or less important options for managing installed apps, and three other modules have been integrated into the main CLI.

NOTE, if the modules removed in this version are missing locally, some options (for example, the one to remove the apps) may not work if you keep using a previous release:

update now!

In the screenshot, the 10 modules that must be present in the "modules" directory (in order from lightest to heaviest), for both "AM" and "AppMan":

New users will have the new configuration directly.

Less are the modules to download, quickier is the full update time:

• New module "management.am" that replaces "remove.am", "no-updates.am", "nolibfuse.am" and "rollback.am", so it includes the following options:

  • '-b' or 'backup', to create snapshots of the applications;
  • '-o' or 'overwrite', to use snapshots created previously (see above);
  • '-R', to remove the applications quickly;
  • '-r' or 'remove', to remove the applications after a prompt;
  • '--rollback', to downgrade installed apps (if a previous version exists);
  • 'lock', to lock the installed app to the current version;
  • 'unlock', to keep update the installed app and previously locked (see above);
  • 'nolibfuse', to convert Type2 AppImages to Type3.

  In brief, all the options you use to "manage" the apps installed from the database.

• The "update.am" and "sync.am" modules have returned to being part of APP-MANAGER, given their "core" importance;

• The "clean.am" module has also been integrated into APP-MANAGER, given its size;

• Removed the five (5) modules "remove.am", "no-updates.am", "nolibfuse.am", "rollback.am" and "clean.am", this is why it is important to update;

• The old "update.am" and "sync.am" modules instead have been retained, to be used by old versions to perform the upgrade, but which will be ignored both in the new installations of "AM" (script "INSTALL") and in future updates (options -s and -u);

• If you have updated now from a previous version, obsolete modules will be automatically searched for and removed starting from the second update;

• Added a header to each module, to briefly explain what each of them does.

This release leads to a slightly faster general update, given the reduction in modules.... but also the possibility of intervening more quickly on single options and on APP-MANAGER itself, given the less dispersive nature of the modules caused by modularization in version 6.

With these changes it was also possible to solve some minor problems, such as updating individual apps that did not show the correct version of the new app, and vice versa, rolling back an app, whose version did not change.

---

Finally, I'm proud to announce that, for the x86_64 architecture, our database now includes...

...2000+ installation scripts!

To view all the apps available in the database visit our site:

https://portable-linux-apps.github.io

---

Full Changelog: 6.8.4...6.9

"AM" 6.8.4

Improvements in checking installed app information

• it is now possible to fully view the versions of the installed apps;
• improved app classification, in particular in the comparison between "script" and "binary/executable";
• the availability of absent versions or the classification of apps as "other" or "unknown" has been reduced to almost zero;
• where the version is absent, at least the part of the "version" file that is considered most relevant will be displayed (for example a "flag");
• fixed some installation scripts;
• refactored the "files.am" module.

Among other changes:

• fixed an issue related to the "--system" option for "non-AppMan" users, which was inaccessible after starting "--user" for the first time but without configuring AppMan;
• fixed a problem in updating APP-MANAGER in "AppMan mode" by non-privileged users.

Full Changelog: 6.8.3...6.8.4

"AM" 6.8.3

Minor fixes to the CLI, modules and... some installation scripts

• in the wake of the previous version, add a function to check versions of auto-updable apps (for example firefox and thunderbird)
• reconstruction of basic information for installed apps occurs after removing an app or converting it from AppImage Type2 to Type3
• allow the update of APP-MANAGER script in "AppMan Mode"
• fixed missing table title in "-f"
• various bug fixes and improvements

I generally don't talk about improvements to individual installation scripts, but here it is necessary:

• updated and improved the installation script for Filezilla, for both x86_64 and i686 architectures
• now the script to install MPV allows you to choose between two different AppImages, as happens with Libreoffice

Full Changelog: 6.8.2...6.8.3

"AM" 6.8.2

Improved the speed of the lists

Improved the speed of the options -a/about, -l/list and -f/files.

The function to check the versions of installed applications takes a long time to generate a list, especially if there are a lot of installed apps.

If the "version-args" file already exists, you no longer need to recreate it from scratch. You could also just create it:

• when apps are installed (option -i);
• when updates are made (option -u);
• when the file is not present (for example using the option -c).

In the latter case, the first time you launch one of the affected options you may experience a slowdown, but all subsequent times you will rely only on the existing file.

As for the option -f, it also relies on a function that checks the type of app installed, so if the file listing the details of installed apps already exists, it will be preserved, unless they have been previously removed applications. In this case this list will be created again, while the version list will be left intact.

"AM" 6.8.1

New installation interface for "wget", consistent with "wget2"

Given the imminent implementation of "wget2" in distributions like Fedora which, since version 40, has completely replaced "wget" with a symbolic link, I changed the loading interface from "dots" to "bar". This is also to show the user what is actually being downloaded.

wget

wget2

---

Other changes include:

• corrected the download line for APP-MANAGER in the "sync.am" module, to allow updating "AM" also in "AppMan Mode" (see new option --user, "AM" 6.8);
• fixed some bugs in "template.am"
• reached 1987 in number of installation scripts for the x86_64 architecture, thanks to @Samueru-sama

Full Changelog: 6.8...6.8.1

"AM" 6.8

Easily switch from "AM" to "AppMan" and back to "AM"

Improved the option --user or appman, now its easier to switch from a CLI to another.

To enable the "AppMan Mode" in "AM" use the command:

am --user

An empty file named "appman-mode" will be created in "$HOME"/.config/appman, near the existing "appman-config" file.

In this way "AM" will be able to manage apps locally using the configuration files of "AppMan".

Having also "AppMan" installed near "AM" is no more necessary.

To use "AM" as "AM" normally, at system level, run the command:

am --system

The empty file named "appman-mode" will be removed from "$HOME"/.config/appman and "AM" will handle the apps installed at system level.

Here is a quick view using the option -f and -i in "AppMan Mode":

simplescreenrecorder-2024-05-17_16.33.55.mkv.mp4

The new option "--system" can be used also from "AppMan" but the option "--user" is not allowed, as always, for obvious reasons.

Also, the new "AppMan Mode" relies on the configuration files of "AppMan" and uses all its modules.

This feature is very useful in systems managed by multiple users, allowing at least local installation of applications and without having to install "AppMan" externally.

What's Changed

Full Changelog: 6.7.1...6.8

"AM" 6.7.1

Let's start once again

This release introduces:

• a cleanup of the general code
• updating all installation scripts and consequent reduction of the patches to be applied to them ("-i" option)
• the separation of functions for standalone use of the same and the reduction of duplicates
• the introduction of new environment variables to be used in subsequent versions
• resolution of various bugs, including one related to the creation of AppImage launchers ("--launcher" option) and the tracking of installed app versions

Most of the uploads are due to @zen0bit, especially the installation scripts and the introduction of new github workflows for automatically correcting syntax on new commits.

The next release should begin moving working directories from "$AMPATH/.cache" to the "$HOME/.cache" directory, for more inclusive use in multi-user systems.

"AM" 6.7

Two new options for developers and beta testers

Added two new options that allow you to use the "dev" branch with all new features (for beta testers and brave hearts)

To enable this, run

am --devmode-enable

or

appman --devmode-enable

Downloading of modules will be performed from the enabled branch. "main" is the default, while "dev" will be used if enabled with the"--devmode-enable" option.

To disable this, run

am --devmode-disable

or

appman --devmode-disable

Other changes

• Solved a bug in "--launcher" where some launchers were not shown due to a missing "Name=" entry;
• Started code refactoring by @zen0bit (first module updated, launcher.am);
• Added a function that helps people with a non ordinary Linux distro and package manager to install the "jq" dependence from the upstream
  
  if the presence of an ordinary package manager is detected (apt, dnf, pacman, emerge...), you will simply be asked to install it from there.

---

From this release, each special operation will have a dedicated branch and major updates will be extensively tested by the AM team for at least a week, in the "dev" branch. If you want to join the development and report bugs and various improvements in the code of future versions, simply enable the "dev" branch and report any problems to us.

They tested, proposed and participated in this version @nazdridoy @zen0bit @Samueru-sama