AM and AppMan, two CLI AppImage Managers based on shell... what about to use them as engines for your software center?

[ivan-hc]

Hi, I've developed two application managers for Appimages and other standalone apps:

• "AM" Application Manager, installs everything in /opt (according to the Linux Standard Base), a launcher in /usr/share/applications (with "AM-" as suffix) and a symlink or a script that redirects to the installed app in /usr/local/bin. This is the scheme:

  /opt/$PROGRAM/
  /opt/$PROGRAM/$PROGRAM
  /opt/$PROGRAM/AM-updater
  /opt/$PROGRAM/remove
  /opt/$PROGRAM/icons/$ICON-NAME
  /usr/local/bin/$PROGRAM
  /usr/share/applications/AM-$PROGRAM.desktop
  

• AppMan, a copy of AM that instead installs all the apps into a directory you choose in your $HOME, all it does is to convert the scripts for AM into scripts that can install everything locally. This is the scheme instead (with, for example, a directory that we want to give "Applicazioni" as name, the italian of "applications"):

  ~/Applicazioni/$PROGRAM/
  ~/Applicazioni/$PROGRAM/$PROGRAM
  ~/Applicazioni/$PROGRAM/AM-updater
  ~/Applicazioni/$PROGRAM/remove
  ~/Applicazioni/$PROGRAM/icons/$ICON-NAME
  ~/.local/bin/$PROGRAM
  ~/.local/share/applications/AM-$PROGRAM.desktop
  

The Appimage managed are more than 1700, you can read more about the installed apps on my own catalogue:

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

I hope this idea can help you improve your distribution.

PS: I'm also a packager for Appimages, this is the list of my AppImages, including scripts I developed to create them

https://github.com/ivan-hc#creating-appimage-packages

Cheers.

[UriHerrera]

Hi there. Thanks for sharing your work and starting a discussion.

Regarding your proposal to use AM and AppMan as backends for the NX Software Center, the Software Center uses C++ code for its internals. We created the Software Center as a graphical interface to manage AppImages exclusively. In this context, the Software Center doesn't manage other types of executables, such as those that a user would put in the directory /opt.

Also, the Software Center places new AppImages in the user's home in the directory /Applications by default. It does not manage files in the root directory since AppImages don't need root privileges to be "installed" or to update and remove the AppImage files.

For the NX Software Center to take advantage of the AppImage files you've created, it can use an API supplied by https://portable-linux-apps.github.io/apps.html to list these files in the UI. That's something we've done in the past with other websites that provided AppImages; see Nitrux/nx-software-center#105.

Unfortunately, we've also been "burned" when these websites stop working, resulting in users having the wrong idea that the application doesn't work; see Nitrux/nx-software-center#129.

So, with that in mind, you can create an issue at the repository of the Software Center so that we can work together to add your listing as a source.

[Samueru-sama]

Hello @UriHerrera I'm a contributor at AM/AppMan, please consider adding AM database to nitrux, I know this isn't easy but appimagehub is a really bad site full of random outdated binaries without even a source.

I noticed on the webiste you suggest using firejail, that's also not very good, firejail is no longer recommended method for sandboxing to the point that it has been removed from alpine as result.

In AM we have easy sandboxing with aisap, which uses bubblewrap I also think we have a much better catalog in which applications are up to date, with a source, etc.

And more recently we will start flagging the appimages that don't have a transparent build process behind them, which I noticed we have a few that are that way.

In any case, if adding Ivan's website is not possible, also please consider shipping appman in Nitrux, all that has to be done is add the appman script in ~/.local/bin and make sure that by default that location is in PATH, everything else would be handled by appman.

[UriHerrera]

Hi @Samueru-sama, thanks for commenting.

Let me sort some things and I'll get back to you both.

[ivan-hc]

I know you had problems with apprepo, but my site is based on github https://github.com/Portable-Linux-Apps/Portable-Linux-Apps.github.io so it should not disapeear so easily.

About installing apps in /opt or /Applications, you if not with AM, you can use AppMan.

Also my installation script are also available as raw files, so you can use any script to detect only the download link to the latest apps available from there. Most of them are only available in $version environment variable (not all, but many of them).

[UriHerrera]

Hi there.

Right now, the best we can offer regarding your utilities, AM and AppMan, is to feature them in our tutorial about Software Management as alternatives to the utilities we include in the distribution by default.

As I mentioned, the NX Software Center uses C++ for its internals. We never designed it to support other "backends" as it's also not intended to be modular, i.e., have a plugin system. As I described, the application can show the files on a website if it provides an API that lists the files and their metadata, as AppRepo or AppImagehub.com does.

An option is to upload the AppImages listed on your website to AppImagehub.com, saving any work on the applications side. It'd only be a matter of updating these uploads by establishing a schedule.

If you're interested, you can to join the Telegram group or the chat at Gitter.

[ivan-hc]

Hi, sorry for the really late answer.

In the last year I've done a big code refactoring and reviewed a lot of installation scripts. I've done a lot of work in my repositories.

Among the most important changes, I've merged "AM" and AppMan into one project: https://github.com/ivan-hc/AM

The project is growing, has more and more collaborators and many more features.

So I had to work a lot on my projects. I hope they can interest you, now more than before.

Now, it's best if I respond to two important points of your last reply, sorry for the wait:

1. About sources and applications

As I mentioned, the NX Software Center uses C++ for its internals. We never designed it to support other "backends" as it's also not intended to be modular, i.e., have a plugin system. As I described, the application can show the files on a website if it provides an API that lists the files and their metadata, as AppRepo or AppImagehub.com does.

Now the installation scripts are almost all the same, it is enough to identify the lines that begin with "version=" and "wget":

• the first line is a variable which could be a number or an entire URL to be identified via a command, to point to the latest available version. In SHELL you can expand it with eval;
• the second can contain a URL or directly the "$version" variable. Obviously this is used to download the app.

Another note, check if the installation script contain the "mage$" keyword. In fact, not all scripts install AppImages, but also standalone applications.

My database now has more than 2100 installation scripts, and about 2000 of these are for AppImages.

And all installed apps are updatable, for real, and have transparent sources, if not in the pages of the catalogue (that can be updated by the users), in the installation scripts.

2. About uploading apps on Appimagehub.com

An option is to upload the AppImages listed on your website to AppImagehub.com, saving any work on the applications side. It'd only be a matter of updating these uploads by establishing a schedule.

I'll be honest with you, I hate that site!

I wrote my catalog precisely because I have my own conception of what a catalog for AppImages should look like to be reliable, and I have a very bad opinion of Appimagehub.com, or the "Pling" ecosystem in general. And I have a certain aversion towards those accounts that upload a lot of products, even though they are not the developers, and that in fact earn from donations that they don't deserve.

I saw an AppImage of mine uploaded up there by a user, and there was no source. I downloaded and extracted it out to realize it was mine. So mine is not an unmotivated hatred.

I don't know how attached you are to Appimagehub.com, but if it's not something you particularly care about, I recommend you switch to my catalog, at least to receive updated and official sources, and not to download obsolete and potentially dangerous packages, stored in who knows which remote hosting service.

My new catalogue's home page: https://portable-linux-apps.github.io

The list of applications (with icons): https://portable-linux-apps.github.io/apps.html

[UriHerrera]

Since we're no longer developing the NX Software Center, this proposal is no longer viable.

I apologize for the very late response.

[ivan-hc]

of all of them, only bonsai have an AppImage release, are you sure they are not hosted somewhere else?

[UriHerrera]

Ah, right, I forgot about that. The pipeline that used to generate the AppImages is no longer functional, and older builds have been removed from KDE. I was under the impression they were still available. The pipeline was using appimage-builder, but since it's no longer maintained, and the person who created the pipeline no longer collaborates with us, there was no point in keeping it alive.

Also, since my focus has been on NX AppHub, and I intend to provide the apps there, it wasn't my priority to take over the AppImage pipeline; sorry.

[ivan-hc]

Also, since my focus has been on NX AppHub, and I intend to provide the apps there, it wasn't my priority to take over the AppImage pipeline; sorry.

Don't worry. If you have a source where AppImages for NX AppHub are hosted, let me know. I'll try to distribute them with AM, if you agree.

[ivan-hc]

Also, since my focus has been on NX AppHub, and I intend to provide the apps there, it wasn't my priority to take over the AppImage pipeline; sorry.

Don't worry. If you have a source where AppImages for NX AppHub are hosted, let me know. I'll try to distribute them with AM, if you agree.

AM also manages other portable formats, not just AppImages.

And near the AM database, there are other third-party databases that also can be managed like this. Apps are listed in this other repo

https://github.com/ivan-hc/am-extras

A more detailed table for x86_64 third-party databases is here

https://github.com/ivan-hc/am-extras/blob/main/ALL/x86_64.md

If you want, you can list your apps into a list or a json file, or whatever text file you want, I can adapt a script to create a third-party database named "nitrux", or whatever name you want, the same way the already available ones are listed in the help message of AM (command am -h)

[UriHerrera]

Also, since my focus has been on NX AppHub, and I intend to provide the apps there, it wasn't my priority to take over the AppImage pipeline; sorry.

Don't worry. If you have a source where AppImages for NX AppHub are hosted, let me know. I'll try to distribute them with AM, if you agree.

The NX AppHub Apps repository does not contain binary files, only YAML files. By design, the files are built locally by the NX AppHub CLI, so unless someone else builds them and uploads them somewhere, they won't be available.