Software 42835 Published by

AM-Application-Manager 8.1 has been released.



"AM" 8.1

"AppMan" can install apps also in directories that are not the $HOME, "AM" can be packaged for distributions and a new option -ia for AppImages is now available!

As the title suggests, this release brings with it three very important new features, let's proceed in order.

1. "AppMan" can install apps also in directories that are not the $HOME

From now on you can choose a directory other than $HOME for the installation of your applications, even an external partition, as long as you have permissions to write to it.

This new feature makes "AppMan" already a step forward compared to "AM".

Thanks to  @Samueru-sama for this improvement!

2. "AM" can be packaged for distributions

For those who decide to package "AM" for the repositories of some distribution, it is necessary to take into account this function inside the APP-MANAGER script, which is the heart of "AM"/"AppMan":

# DETERMINE WHEN TO USE "AM" OR "APPMAN"
if [ "$(realpath "$0")" = "/opt/am/APP-MANAGER" ]; then
	_am
	mkdir -p "$MODULES_PATH" || exit 1
elif [ "$(realpath "$0")" = "/usr/bin/am" ]; then
	_am
	AMPATH="$AMCACHEDIR"
	MODULES_PATH="/usr/lib/am/modules"
else
	_appman
fi

the above function specifies that if the "am" command is in /usr/bin, the "AMPATH" variable will be set to a writable directory (in our case we used "AMCACHEDIR", the $HOME/.cache/am directory) while the "MODULES_PATH" variable will be set to the system directory "/usr/lib/am/modules" you created, thus overriding the default values ​​of "AM".

for this to work, you need to rename the "APP-MANAGER" script to "am" and place it in /usr/bin, while the "modules" directory must be placed in /usr/lib/am. Here is how a package structure should look like, according to the definitions currently in force:

/usr/bin/am
/usr/lib/am/modules/database.am
/usr/lib/am/modules/install.am
/usr/lib/am/modules/management.am
/usr/lib/am/modules/sandboxes.am
/usr/lib/am/modules/template.am

the above scheme has already been tested on Debian Stable, a demo video is available  here.

For this "special" redistribution, module updates and the CLI itself will be disabled, which will instead have to be managed by the package manager in use (APT, DNF, Emerge, YAY...).

NOTE, the above scheme may be changed, according to the distribution packagers' decisions. Suggestions for improving the implementation are welcome.

3. New option -ia for AppImages is now available

Like the option -i/install, but for AppImages only! Its now available the new option "-ia" or "install-appimage"!

USAGE:

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

or

appman -ia {PROGRAM}
appman -ia --debug {PROGRAM}
appman -ia --force-latest {PROGRAM}

In this example, I'll run the script brave-appimage but running brave, that instead is the original upstream package:

 install-appimage-2024-08-29_17.49.07.mkv.mp4 

in the video above I first launch a "query" with the -q option to show you the difference between brave and brave-appimage, and then -q --appimages to show you only the appimages from the list.

All the new option "-ia" does is to check on the AppImage's list if the "argument" exists, if not, another check will be done by adding "-appimage" at the end of the argument. If no argument is found, the command -i will not not be launched, while if the argument exists, the option -i will take care of the installation of the script and also of the flags --debug and --force-latest, if they exist.

NOTE: by definition, the AppImages themselves "are not installed", but by installation we of the "AM" team mean adding the package, with its symbolic link, the version file, the icon directory and the script to update the application all, overall, in the dedicated paths. Generalizing, and above all for practical reasons, of language and syntax, we simplify the whole thing by calling this option "install-appimage", or simply "-ia", in PacMan/YAY style.

What's Changed

Full Changelog 8...8.1

Release "AM" 8.1 · ivan-hc/AM