appimage.github.io icon indicating copy to clipboard operation
appimage.github.io copied to clipboard

Almost 30% of the entries are useless

Open zocker-160 opened this issue 2 years ago • 13 comments

I created a python script which uses the information available and checks the provided urls and I found out that almost 30% of the packages

  • do not have any download url (around 256 packages)
  • download url returns 404 (around 31)
  • does not offer an AppImage in the releases because they stopped offering one (around 129)

here the script (rename from txt to py, GitHub does not accept .py files):

Appchecker.txt

and here my results including the list of applications in each category:

results.txt

I think it would be good to clean this up a bit, because otherwise this repository will become more and more useless and frustrating for users.

zocker-160 avatar May 24 '22 21:05 zocker-160

Thanks for checking @zocker-160. Would you be willing to help keep this directory recent? But we should not just remove entries, instead we should follow up with the projects to see why things broke. Unless the projects themselves are gone, of course.

probonopd avatar May 24 '22 22:05 probonopd

I created this script, because I came across multiple useless entries when searching for AppImages and instead of complaining I though it would make sense to find out which ones are broken and why.

I am not quite sure how I could be helpful with this, I think it would make sense to run this script as a GitHub action and then clean it up bit by bit. Considering that it is almost one third of the packages, it will be a good amount of work.

I release the script under public domain, so feel free to use it as you see fit.

EDIT: one additional note, the GitHub rate limiter is quite a problem, so the script takes good 15 - 20 minutes to complete

zocker-160 avatar May 24 '22 23:05 zocker-160

Quickly looked at your list. Plenty of applictions that you list under "Following items have no URL at all" actually are still alive and well, and are publishing AppImages. So I think you are expecting that all entries in this directory have a direct download link. Thant is not how it works, however. We can, for technical reasons, only show direct download links if

  • The AppImage is hosted on a known infrastructure like GitHub that we have specific support for; and/or
  • The AppImage ships, inside its AppStream data, a link to its download page In other cases, we simply don't know where to link to. So it could be that many of the "Following items have no URL at all" are false alarms.

In the " Following items' URL returns error code" category, we need to see what happened to them. Especially if 404 is returned, it can mean the project no longer exists, the project has moved to another location, or the project doesn't currently publish AppImages. Here one needs to check fo each project which of those is the case.

For the "Following items' release page does not contain an AppImage file in the latest release", this could mean the project has moved the AppImage to a different location or is simply not offering an AppImage for the latest release (but for at least one earlier one). Here one needs to follow up with the project, see whether the AppImage is at a new location, or ask the project to provide an AppImage for the latest release.

TODO list growing larger and larger. Volunteers?

probonopd avatar May 25 '22 05:05 probonopd

Yes I am expecting an url, because entries like this

https://appimage.github.io/Bridge/

are useless.

zocker-160 avatar May 25 '22 13:05 zocker-160

In this particular case, there is an AppStream metainfo file missing in the AppImage that would contain the URL to the correct page, https://quixel.com/bridge. The AppImage is available for download there. One would need to work with the authors to get them to incclude an an AppStream metainfo file int he AppImage, and then run the new AppImage through the automated test again.

probonopd avatar May 25 '22 16:05 probonopd

ah ok understood.

The do not have any download url category is mostly this issue though, where it has no url specified. So my assumption that those projects do not offer an AppImage is wrong, but I think my point still stands, that those entries are not very useful, since I would expect a download link to be available.

zocker-160 avatar May 25 '22 16:05 zocker-160

Agree. We just need volunteers to improve this.

probonopd avatar May 26 '22 09:05 probonopd

I will try to fix all non-existent/incorrect data as well as add new applications in the coming days

Drsheppard01 avatar Jul 22 '22 11:07 Drsheppard01

@probonopd Also none of the KDE apps have download link although I don't know if they contain an AppStream url or not.

prateekmedia avatar Aug 07 '22 07:08 prateekmedia

@probonopd Also none of the KDE apps have download link although I don't know if they contain an AppStream url or not.

I'm fixing it now, some kde (peruse) applications are not available at all, some are built via jenkins

Drsheppard01 avatar Aug 07 '22 08:08 Drsheppard01

I'm fixing it now

We are not manually maintaining this kind of information in this repository, so it needs to be fixed in the upstream AppImages, from which the automated test needs to be able to extract the respective AppStream information.

Please ask if it is not clear what I mean by this. In any case, please do not manually edit any xml or md files in this repository. Thanks!

probonopd avatar Aug 07 '22 17:08 probonopd

Please ask if it is not clear what I mean by this. In any case, please do not manually edit any xml or md files in this repository. Thanks!

I forked and amend the links in markdown. If the site is launched, will it break it?

Drsheppard01 avatar Aug 07 '22 17:08 Drsheppard01

The markdown is automatically generated by the test script each time the test runs. So manual changes would be overwritten immediately. The things need to be fixed inside the AppImages.

probonopd avatar Aug 07 '22 18:08 probonopd