appimage.github.io icon indicating copy to clipboard operation
appimage.github.io copied to clipboard
verified publisher icon AppImage

Make this a community effort?

Open probonopd opened this issue 3 months ago • 9 comments

tl;dr: Let's consider to make this repository a true community effort, or merge/replace it with another.

Some history first. A long time ago, I invented the AppImage file format so that I (and you!) could:

  • Run a "normal" Linux distribution (preferably Debian stable, later Ubuntu LTS at the time)
  • Download an application directly from the author (like I can for Windows and the Mac), ideally at the day when a new version comes out (something not possible with Debian stable and Ubuntu LTS)
  • Do so on a Linux Live ISO or lab machine without the need for a root account nor a package manager - I specifically wanted to download a file from a download page on the software author's website (usually next to the release notes) and be able to run that

After I had published the AppImage file format and tools, I noticed that AppImages started to appear "in the wild", but more often than not, they were not properly made and would not run on my system, giving a bad impression to users that "AppImages wouldn't work".

When I started this repository, it was a means for me to quickly identify AppImages that needed help. Back in the time ~80% of the AppImages I found on the Internet were not working on the oldest still-supported Ubuntu LTS, and in my experience people were simply not aware how to build AppImages that are as binary-compatible with as many Linux distributions as possible.

Over 6,500 commits to this repository later, the situation has somewhat changed:

  • As of today, this repository has 1469 tested apps (that passed our test at least once during their lifetime)
  • By contrast, https://portable-linux-apps.github.io/ has 2218 listed apps
  • Longtime AppImage co-maintainer @TheAssassin never was a fan of this repository to begin with, and even for me it has been more a necessary chore than something I enjoy doing
  • There are now community members like @Samueru-sama and @ivan-hc who have, over the past years, shown a lot of dedication and effort around the AppImage format, and have gained a detailed understanding of how to build AppImages that not only really work everywhere (like what we did together for PrusaSlicer) but even in a (https://github.com/pkgforge-dev/archlinux-pkgs-debloated)[debloated] way
  • There are increasing complaints that this repository would require more maintenance, something I don't have the time for

So I am wondering (just wondering - nothing is decided yet!) whether we could hand this repository over to the community, merge it with https://github.com/Portable-Linux-Apps/Portable-Linux-Apps.github.io, or simply point to the latter.

https://portable-linux-apps.github.io/ was made as a by-product for AM, a package manager for AppImages. While I personally have no desire to use a package manager for AppImages (in fact, I designed the format specifically so that none would be needed anymore), I recognize that some people like to have one. And if the package manager has a collection of known-good AppImages, why not use that for users like me who don't want a package manager, too.

What makes an AppImage "known-good" for me?

  • It works without having to install any packages that are not installed by "every" (major) Linux distribution by default on its Live ISOs
  • It works without requiring always the latest and greatest version of libc and whatnot (needs to run at least on Debian stable, better oldstable, and the oldest still-supported Ubuntu LTS)
  • Even more ideally, has no dependencies other than the kernel, because it bundles everything (at the expense of some overhead). Let's call these "self-contained" AppImage. Things like archlinux-pkgs-debloated can help creating those
  • At least a screenshot can be taken in an automated test, showing there is a window with some content (not just a while blank screen as it very common with Electron based apps), even when there is no connection to the Internet
  • Contains nothing unnecessary inside the AppImage (e.g., not the whole usr, bin and sbin trees from a full-blown Linux distribution, as would be the case with a distro chroot)

So the question is, does Portable-Linux-Apps.github.io share similar goals or could we have a conversation about them for the future?

Going forward, I'd like to focus on

  • Refining the AppImage file format and its specs
  • Refining the core AppImage tools (e.g., the runtime)
  • Helping desktop environment developers to support the format natively

and not so much on

  • Creating build systems to produce what goes into AppImages
  • Maintaining a catalog of "known-good" AppImages

@ivan-hc, @Samueru-sama, and everyone else interested in this topic, what do you think? Would it be imaginable that we work together in this area?

probonopd avatar Dec 06 '25 13:12 probonopd

@probonopd Personally, if I created the catalog, it is also to keep track of the AppImages that still exist. There are many listed in your catalog, and some of them come from projects that no longer exist, or that exist but have stopped producing AppImage packages.

My catalog is not just a byproduct of AM. My package manager also serves to identify and track AppImage usage among developers, via this other repository of mine:

https://github.com/ivan-hc/amcheck

In this repository, AM installs 250 applications every hour, testing their scripts, and therefore their real availability on the web:

https://github.com/ivan-hc/amcheck/actions

In this sense, if an app no longer exists or has problems being installed/downloaded, I investigate the problem using the installation script available in AM:

  1. if the source no longer exists, I remove the script, and consequently Github Actions will also remove the dedicated page on my catalog within an hour
  2. if the source exists but the AppImage has problems (for example, being extracted with --appimage-extract, to get the .desktop file, most of the time, and such option does not work on that file, maybe because it had problems when released and it is a fake AppImage, empty, most of the time), I try to contact the upstream developer. In the meantime I'm blacklisting the app. If I don't receive a response within a week or 2, I remove the script (see point 1)
  3. if the app exists, it is downloadable and extractable BY THE USER, but Github Actions has problems reaching the online domain (due to filters that reject calls from github.com), I work on a way to also allow Github Actions to download the program... but if I can't, I blacklist the app (it remains in the database, but I don't test it via Github Actions), and so far there are few apps that "enjoy this privilege" https://github.com/ivan-hc/amcheck/blob/e29e2e74a206787c418fd0134600fc75e086f7f6/.github/workflows/AMCHECK.yml#L344-L357

This work is mostly thanks to @zen0bit, who worked on the workflows himself.

I understand that you don't like "AM" and wouldn't personally use it to manage AppImages. But as a developer, you can use it as a tool, to check its availability and quality, via "amcheck".

That said, I would be honored if our plans converge in some way.

I want to push for the use of AppImage, and help those who adopt it if the tools they use are old and problematic.

We already had the opportunity to test my VirtualBox-KVM on your catalog, and it turned out to be a valid AppImage (even though it was an Archimage, so it won't work on freeBSD... yet). I'm interested in the testing model actually, the fact that added apps are executed and validated. I find your catalog very useful in this regard.

Maybe it would be even more complete with dedicated pages containing descriptions, download buttons... and apps that still exist.

I believe that our catalogues, together, can compensate for each other's shortcomings, so I am open to collaboration.

ivan-hc avatar Dec 06 '25 16:12 ivan-hc

Hi @ivan-hc, thanks for your reply. Over the past years, I've had a chance to see the amount of dedication and quality work you have done for the AppImage ecosystem. While I still won't use a package manager for managing AppImages on my personal system, I really appreciate your effort. And I understand that your catalog is also valuable outside of the package manager. So I would be happy if we could find a way to work together on an AppImage catalog that combines the strengths of your and my existing catalogs.

I am always wondering how you and @Samueru-sama can produce so much quality output so consistently, and I guess clever automation plays a role. So maybe you would consider to add a workflow to your catalog that would download and test each AppImage at least once before initially adding it to your catalog? (One could ever run the check periodically - or, if your catalog tracks versions, for every version.)

The main test script in this repository is a long shell script that basically just download the AppImage that is referenced in a pull request, executes it, and takes a screenshot after a while. I manually check each screenshot before merging. The same script also extracts all the meta information (name, description, etc.) from inside the AppImage, since I don't want to spend time to manually maintain such information. Let me know if you have any questions about it.

If we wanted to go a bit more strict, we could even make the test script run inside a Alpine Linux chroot or something like that - then only AppImages that bundle everything would pass. (That's probably the way to go for the future, would you agree?)

probonopd avatar Dec 06 '25 17:12 probonopd

I am always wondering how you and @Samueru-sama can produce so much quality output so consistently

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/main/HOW-TO-MAKE-THESE.md

The reality is that the moment you bundle everything it becomes much much simpler, no need to test of 4 separate distros, just checking in a minimal alpine container is more than enough.

  • sharun uses strace to find the dlopened libraries, this has always been a pain with other tools that just pretty much just run ldd and have some stuff coded manually like the Qt plugins.

Samueru-sama avatar Dec 06 '25 17:12 Samueru-sama

The reality is that the moment you bundle everything it becomes much much simpler, no need to test of 4 separate distros, just checking in a minimal alpine container is more than enough.

So maybe that's the approach we should all evangelize and test for going forward.

probonopd avatar Dec 06 '25 18:12 probonopd

I wonder what we could make together if the three of us (and possibly some more) devs spent a day together in a (virtual) room 💯

probonopd avatar Dec 06 '25 18:12 probonopd

I will state that I'm not interested in managing the website, that is something I will leave to Ivan to do or someone else that wants to take my place.

I just dedicate my time to packaging.

Samueru-sama avatar Dec 06 '25 18:12 Samueru-sama

I will state that I'm not interested in managing the website, that is something I will leave to Ivan to do or someone else that wants to take my place.

I just dedicate my time to packaging.

This is true @probonopd , I tried several time to involve Samu (without success).

I also added github actions to create the pages starting from the description f x86_64 apps and their site reference in the installation script, to save time (yep, to handle the catalogue is a pain also for me 😆 )

ivan-hc avatar Dec 06 '25 18:12 ivan-hc

@probonopd you can fork the repo of the catalogue and try to add your script at this (empty) line https://github.com/ivan-hc/amcheck/blob/b0dfff66283c7ce1ad45a8702cf7d9d7043b9e16/.github/workflows/AMCHECK.yml#L452

Installed apps are located this way: /opt/appname/appname

That said, you know once the app is downloaded, where you can get it to check if it is a valid AppImage.

NOTE that this step https://github.com/ivan-hc/amcheck/blob/b0dfff66283c7ce1ad45a8702cf7d9d7043b9e16/.github/workflows/AMCHECK.yml#L287-L296 checks if the file is an AppImage, so you should run the test only if [ "$APPIMAGE" = "yes" ]

This is because the package manager also installs (for now) 403 portable programs (not in AppImage format), also if we are trying to port all of them to AppImage, the same way we already do here

  • https://github.com/Portable-Linux-Apps/Telegram-AppImage
  • https://github.com/Portable-Linux-Apps/IceCat-AppImage
  • https://github.com/Portable-Linux-Apps/Lorien-AppImage
  • https://github.com/Portable-Linux-Apps/Waterfox-AppImage
  • https://github.com/Portable-Linux-Apps/ruffle-AppImage
  • https://github.com/Portable-Linux-Apps/floorp-AppImage
  • https://github.com/Portable-Linux-Apps/palemoon-AppImage
  • https://github.com/Portable-Linux-Apps/mullvad-browser-AppImage
  • https://github.com/Portable-Linux-Apps/fastfetch-AppImage

or

  • https://github.com/ivan-hc/Chrome-appimage
  • https://github.com/ivan-hc/MS-Edge-appimage
  • https://github.com/ivan-hc/Vivaldi-appimage
  • https://github.com/ivan-hc/Yandex-Browser-appimage
  • https://github.com/ivan-hc/Blender-appimage
  • https://github.com/ivan-hc/Calibre-appimage
  • https://github.com/ivan-hc/Discord-appimage
  • https://github.com/ivan-hc/Firefox-appimage
  • https://github.com/ivan-hc/PowerShell-appimage
  • https://github.com/ivan-hc/SuperTuxKart-appimage
  • https://github.com/ivan-hc/Thunderbird-appimage
  • https://github.com/ivan-hc/UrbanTerror-appimage

and in part at

  • https://github.com/ivan-hc/Database-of-pkg2appimaged-packages

ivan-hc avatar Dec 06 '25 18:12 ivan-hc

Hi all. I'd be happy to help build the website if needed.

I'm an avid user of @Samueru-sama's AppImages and work closely with him to test new builds. I run a particularly specific Alpine (aka musl) setup. Regular AppImages do not work at all. Until i saw the AppImages from @Samueru-sama (and the lads from https://github.com/pkgforge-dev/Anylinux-AppImages).

xlc-dev avatar Dec 06 '25 19:12 xlc-dev