"AM" 7.6.2

Database transparency, here are the real numbers

From now on the -l or list option will show the total number of "real" applications only, therefore without including the helpers for "kdeutils" and "kdegames" or the reintroduced "adb"/"fastboot" and "npm" (for "platform-tools" and "node" respectively) or web apps.

The change will appear much more noticeable on the catalog, as both "real" apps and "helpers" or "items" will be counted separately.

The purpose of this update is to provide in a clear and detailed way how many applications it is actually possible to install with our package manager:

2120 unique applications, of these 1923 are AppImages. In addition to these, 79 objects are listed, including helpers of real application (for example "kdegames" and "kdeutils") and web apps ("ffwa").

However, "helpers" and webapps will still be searchable and listed in both the list and queries. The change is only in counting.

For more details, visit https://portable-linux-apps.github.io

---

AppImage type name changes

As you may have noticed, already in -f you can see that all AppImages are classified in the same way, that is "appimage". The nomenclatures we used previously, that is "appimage2" and "appimage3", are no longer there.

For those who don't know, we indicated with "appimage2" those that still depended on "libfuse2", while the new generation ones we indicated with "appimage3".

From now on, to distinguish them, it will be necessary to pay attention to the asterisk in -f, those marked, still depend on libfuse2.

The change was explicitly requested by the creator of AppImage (see #818 and #843).

Future implementations will improve support for all AppImages, and "AM"/"AppMan" will be the first to enhance this.

We're just waiting for a certain pull request to be approved...

---

Code refactoring

The install.am module has been refactored, simplifying its functions. The APP-MANAGER code has also undergone some changes.

This will make room for new implementations, which will involve updates to individual AppImages and conversion of old ones into new ones.

What's Changed

• Use "Next Generation AppImage" instead of "Type3" by @ivan-hc in #843
• "AM" 7.6.2: list only real apps + code refactoring by @ivan-hc in #846

Full Changelog: 7.6.1...7.6.2

"AM" 7.6.1

Improved "list" and "query"

A more elegant way to list and query all applications in this database:

To recap:

1. Option -l or list shows the whole list of apps available in this repository. This option uses less to show the list, so to exit its enough to press "Q". If the option -l is followed by --appimages, you will be able to see only the available AppImages.

This new release shows lists with colored item names, removed the invasive message at closing (after you press the "Q" key) and words are not cutted when the line is bigger than the widht of the terminal.

list-2024-08-13_02.35.34.mkv.mp4

2. Option -q or query shows search results from the list above. If followed by --appimages, the search results will be only for the available AppImages. If followed by --pkg, all keywords will be listed also if not on the same line. This is good if you are looking for multiple packages.

Same colored items as -l, but with a more compat list to fit search results in the terminal.

query-2024-08-13_02.36.07.mkv.mp4

---

What's Changed

• database.am Add colors to list by @Samueru-sama in #841
• "AM" 7.6.1: lists improvements by @ivan-hc in #842

Full Changelog: 7.6...7.6.1

"AM" 7.6

Support "doas" as an alternative for "sudo", plus other changes...

Now "AM" can use "doas" as alternative to "sudo".

---

Application list improvements

Now lists can contain more details by default and even more keywords.

this change is useful to improve "categories" on our catalog, https://portable-linux-apps.github.io

Among these info we can add also whether if an application is Official or Unofficial.

---

Categories for the catalogue

Thanks to the am2pla-site script and the x86_64-apps list improved, now it is easier to add and improve categories on the webasite.

Here are all new pages added to https://portable-linux-apps.github.io from this repository:

• https://portable-linux-apps.github.io/appimages.html
• https://portable-linux-apps.github.io/android.html
• https://portable-linux-apps.github.io/audio.html
• https://portable-linux-apps.github.io/communication.html
• https://portable-linux-apps.github.io/education.html
• https://portable-linux-apps.github.io/game.html
• https://portable-linux-apps.github.io/graphic.html
• https://portable-linux-apps.github.io/internet.html
• https://portable-linux-apps.github.io/office.html
• https://portable-linux-apps.github.io/video.html
• https://portable-linux-apps.github.io/web-app.html
• https://portable-linux-apps.github.io/web-browser.html

even more categories will be added in future if you ask for them.

You can help us improving the website's pages by adding more information at x86_64-apps

---

Other changes

• refactoring of the "database.am" module
• fix a bug in -a about sizes of installed libraries
• options -l and -q will use fold -sw 81 to prevent cutting words in long descriptions
• removed the helpers "adb" and "fastboot" (for "platform-tools") and "npm" (for "node").

---

"AM" database statistics

We can divide the installation scripts into "unique programs" (AppImage and other portable formats), "helpers" (keywords to facilitate the installation of metapackages, such as unique programs) and "launchers".

Until today, August 12, 2024, we have 2196 installation sctipts for the x86_64 architecture:

• 1923 unique AppImages
• 197 standalone programs and command line utilities
• 40 helpers for "kdegames"
• 27 helpers for "kdeutils"
• 9 launchers (ffwa, FireFox WebApps, or profiles)

---

Thanks to @Samueru-sama for the "doas" support and for helping me with the application's list!

Full Changelog: 7.5...7.6

"AM" 7.5

Allow "-l" and "-q" to show only available AppImages

As you already know, "AM"/"AppMan" installs and manages not just AppImages, but also portable applications.

This release helps the users of AppImages, the ones that only look for AppImages, thanks to the new suboption "--appimages" to be used in "-q" or "query" and "-l" or "list".

Usage:

am -l --appimages
am -q --appimages ${KEIWORD1} ${KEYWORD2} ${KEYWORD3}

or

appman -l --appimages
appman -q --appimages ${KEIWORD1} ${KEYWORD2} ${KEYWORD3}

simplescreenrecorder-2024-08-08_22.55.41.mkv.mp4

The new lists come from the main ones and only contain unique AppImages, so no helpers for metapackages like "kdeutils" (27) and "kdegames" (40).

"AM" database statistics

We can divide the installation scripts into "unique programs" (AppImage and other portable formats), "helpers" (keywords to facilitate the installation of metapackages, such as unique programs) and "launchers".

Until today, August 09, 20024, this is the situation for the x86_64 architecture:

• 2119 unique programs, and of these...
  • 1922 are AppImages
  • 197 are standalone programs and command line utilities
• 40 helpers for "kdegames"
• 27 helpers for "kdeutils"
• 2 helpers for "platform-tools" (adb and fastboot)
• 1 helper for "node" (npm)
• 9 launchers (ffwa, FireFox WebApps, or profiles)

---

Among other changes

Option "-f" or "files", add notes on appimage2 and appimage3 usage

The names "appimage2" and "appimage3" will remain in effect until the "fusermount" issue is resolved upstream. See #818 for more details.

Full Changelog: 7.4...7.5

---

What next?

Now that AppImages can be listed separately from other apps, helpers and launchers, and have a clearer picture of what we actually have in the database... the next release, 7.6, will start working on verifying AppImages that have verified code and unofficial, closed-source ones, to improve security and help you choose more trusted applications.

Stay tuned!

PS: thanks to @probonopd for this imput

"AM" 7.4

New common installer for both "AM" and "AppMan"

Added a new installer to speed up the installation of "AM" and "AppMan", named "AM-INSTALLER".

Download and run it using these commands:

wget -q https://raw.githubusercontent.com/ivan-hc/AM/main/AM-INSTALLER
chmod a+x ./AM-INSTALLER
./AM-INSTALLER

The installer is based on the existing "AM" and "AppMan" installation methods, already available on the README:

• "AM" (option 1) will download and run the usual "INSTALL" script;
• "AppMan" (option 2) will install the "appman" command in ~/.local/bin (and enable this path in $PATH, if it is not already enabled).

The goal of this script is to make users aware that they want to use this CLI, by providing them with an easy installation and a quick choice between a system-wide ("AM", am command) or local-wide ("AppMan", appman command) installation.

---

Also improved the "INSTALL" script, for "AM"

The "AM" logo has been removed to make room for a more detailed explanation of the processes in place (see the video).

simplescreenrecorder-2024-08-04_16.58.52.mkv.mp4

---

This release does not bring with it major changes in terms of options and functionality, but it informs the user still doubtful and not inclined to reading guides that "AM" can be installed and used locally, without root privileges, but with a different name:

"AppMan", command "appman".

Thanks to @Samueru-sama for contribution

Full Changelog: 7.3...7.4

"AM" 7.3

New option to create portable "$XDG_CONFIG_HOME" directories for AppImages

The new option -C (uppercased) or --config is a frontend of the inbuilt option --appimage-portable-config that aready exists in all AppImages, as -H (uppercased) or --home is for the other inbuilt option --appimage-portable-home.

SYNTAX

am -C {PROGRAM}

or

appman -C {PROGRAM}

These changes are all made by @Samueru-sama :

• Add option -C or --config to create a .config directory for AppImages like it is already done for .home.

• Add check for when the portable config or home directory already exists

tests:

In the test, kek simulates a non-installed package and bemoji a non-appimage package, to test that those checks for those cases are working.

Each run of --home or --config is repeated to also test when the directory already exists.

---

Among other changes:

• improved option -e or extra from release 7.2

---

Among apps changes:

• new AppImages for bottles, gnome-boxes, steam and virtualbox, all based on the excellent "conty"
• kdeutils apps are now 27 into one appimage
• appimages for chromium, chromium-rc, chromium-beta and chromium-edge

---

Statistics on apps available in the database:

• Installation scripts for x86_64: 2150
• Metascripts for x86_64: 4 (kdegames 40 apps, kdeutils 27, platform-tools 3, node 2)
• Unique AppImages (non-metascripts): 1866

---

Full Changelog: 7.2.1...7.3

"AM" 7.2.1

Improved installation of local scripts

• Fixed a bug that prevented local installation scripts from running from the directory where the SHELL was opened
• New criteria to distinguish local installation scripts from online ones

See #793

Among other changes

• Added new environment variable to identify the working directory, "$REALDIR", currently used only for local installation scripts
• Added more functions in the "install.am" module to distinguish installation modes
• Fixed a bug where the /usr/local/share/applications directory was not automatically created
• Fixed a bug in "template.am" where creating installation scripts for creating AppImage packages on the fly required more questions than necessary
• Improved creation of installation scripts using both URLs and commands for apps hosted on random sites (template.am)
• Cleaned and updated installation scripts for 32-bit / i686 architecture
• Installation scripts available for x86_64 architecture are 2126

Full Changelog: 7.2...7.2.1

---

Announcement

I'm looking for volunteers to maintain and add applications for all other available architectures (ARM64/aarch64, x86/i386/i486/i586/i686... and many others).

We try to bring "AM" and "AppMan" to more architectures and more systems.

For more details, please see #784

"AM" 7.2

Install all AppImages not listed in this database but available in other github repos

From now its possible to install AppImages not listed in this database, thanks to the new option -e or extra.

Prologue

You may have noticed that in version "7" there was a sharp drop in the number of apps present in the database, and this is partly due to the new policy on duplicates, i.e. that old apps cannot be introduced if o more updated one is provided by another developer (see "wine").

But my project was born with a mission, to provide you with all the AppImages:

• This update is dedicated to all those who rely on a specific package, even if it is old.
• This update is for you that were unable to notify me of an application to add to the database.
• This update is for anyone using AppImage alternatives to the ones listed.
• This update is for those who don't like the names I've given to some apps.
• And finally, this update is also for those who have a recent ARM64/aarch64 architecture or an old i686/i586/i486/i386, and do not feel supported enough, given my focusing on x86_64 (its the only hardware I have, sorry).

For all of you, it's time to enjoy the full potential of "AM" tools, and without limits!

How it works

You need to add the URL to the github repo before the name you want to give to the AppImage (for command line usage, for example).

Optionally, you can add a "keyword" if more AppImages are listed in the same repo.

Usage:

am -e $USER/$PROJECT $PROGRAM
am -e $USER/$PROJECT $PROGRAM $KEYWORD

or if you're an "AppMan" user

appman -e $USER/$PROJECT $PROGRAM
appman -e $USER/$PROJECT $PROGRAM $KEYWORD

You can give whatever name you want to the apps (as long as they does not overlap with commands already existing on your system, be careful).

in this video I'll install AnyDesk as "remote-desktop-client":

simplescreenrecorder-2024-07-12_01.38.51.mkv.mp4

In this other example, I'll install an obsolete version of WINE AppImage, from a repo that lists more versions of the same app:

1. the first attempt is without a keyword, so that the script picks the first AppImage in the list (for Debian Buster)
2. in the second attempt I'll use the keyword "arch" to pick the Arch-based AppImage

simplescreenrecorder-2024-07-12_02.00.18.mkv.mp4

As you can see, there are all the files needed by any app listed in this database, also if an installation script for them does not exists.

Apps installed this way will enjoy the same benefits as those that can already be installed from the database with the "-i" or "install" option mentioned above, including updates and sandboxing.

Full Changelog: 7.1.1...7.2

"AM" 7.1.1

Continuation of version 7.1 and other little improvements

Installation scripts that can build AppImage packages on the fly will each have their own dependencies to declare. If you come across one of these scripts, the installation module "install.am" will check whether the second script (the one dedicated to building the app) requires specific dependencies, and if it is not installed, the installation will be aborted.

For example:

• you want to install the APP1, that requires "tar"
• also you want install the APP2, that requires "gcc"
• you have "tar" installed, but "gcc" is not installed
• only APP1 will be installed

Currently the list of possible optional dependencies for that kind of script includes:

ar, convert, gcc, glib-compile-schemas, make, tar and unzip

NOTE, THEY ARE NOT "AM" DEPENDENCES, don't worry 😉

This enhances new functionality available with version 7.1.

If you need to create installation scripts to build AppImages on the fly, let me know what are dependences they may need.

Please, reference to https://github.com/ivan-hc/AM/tree/main/appimage-bulder-scripts for the correct path of these scripts.

Also see the video examples from the previous release, now also available on the README.

---

Among other changes:

• the "-f" option now shows the number of installed libraries (which for now is only one available in the database, obviously "libfuse2")
• always the "-f" option will show if there are multiple apps and libraries installed (plural) or there is only one (singular)
  

Full Changelog: 7.1...7.1.1

Also, new homepage is now available for https://portable-linux-apps.github.io

"AM" 7.1

The beauty of DIY: building AppImages on the fly, like an AUR package!

Creating installation scripts for AppImages on the fly (option "-t" or "template", preference 1) is even easier now.

The two functions, assembly and installation, have been divided into two separate scripts:

1. the installation script, which is the same as the AppImages (option "-t", preference "zero") will only have to intercept the package version (necessary for updates) and install the ready-made AppImage;
2. the "assembly" script (with ".sh" extension) will be downloaded by the installation script into the temporary "tmp" directory created at the start of the installation process, so as to be executed and independently build the AppImage, before delivering it to the installation script.

To show you what I mean:

In this video we see how "calibre" is installed (note that a "calibre.sh" file is downloaded during the process):

calibre-installation-2024-07-10_01.46.59.mkv.mp4

In this video, I run the aforementioned "calibre.sh" script in a separate directory, in a completely standalone way:

calibre-standalone-2024-07-10_01.45.04.mkv.mp4

This method replaces the previous one which included both functions in a single body (and which led to the creation of scripts that were too long and complicated to manage).

NOTE, assembling AppImages on the fly can be a time-consuming and resource-intensive operation, depending on the size of the program you want to build.

I suggest contacting upstream developers to convince them to release official AppImage packages, or at least, create them on your own repositories using Github Actions, as I have done over the years.

On the other hand, the advantage of this method is that the update is continuous, using upstream packages and without being limited by the packager, be it official or third party.

You can upload other build scripts at https://github.com/ivan-hc/AM/tree/main/appimage-bulder-scripts

---

If you are a user of my AppImage creation tools

• consider using AppImaGen, it is a simpler and more natural approach for this type of packages.
• try NOT to use Archimage, as build times are longer and more resource intensive.
• try NOT to use Snap2AppImage, it may be resource-intensive too, as Snap packages tend to be very large.

From the next release there should be suitable patches for other tools that use gcc, make and other software assembly systems.

---

Full Changelog: 7...7.1