appstream
appstream copied to clipboard
ximion
Add download page URL
Currently there are several different URL types allowed:
homepagebugtrackerfaqhelpdonationtranslate
Please also define
download
Example for real-world values:
- https://www.libreoffice.org/download/download/
- https://subsurface-divelog.org/download/
- https://github.com/thorpelawrence/pixsrt/releases
This is needed for https://github.com/AppImage/AppImageHub/.
What would download be? Seems a bit vague to me, and I'm not sure where or why you'd use it. If you're pointing to a tarball you can use
It should point to the generic download page with an overview over all available downloads, not to any particular release or download. Maybe it should be called downloads or downloadpage for clarification.
But what would use the download link? Don't we want to handle the install for the user rather than just say "figure it out yourself"?
It's exactly for the "figure it out yourself" cases. E.g., https://yousry.itch.io/memory-the-minor-planets
I must say I am not a friend of the "figure it out yourself" method... If the user has a place where AppStream metadata is already present, why wouldn't that place also allow a direct installation of the piece of software, instead of having the user go to a potentially untrusted site with varying instructions to get what they want?
Paywalls, pay-what-you-like-walls, register walls, all these things exist in the real life. Also sometimes there are different download options which are best handled by a HTML page, such as http://libreoffice.soluzioniopen.com/index.php/old-versions/.
I really think downgrades are better solved using the package manager rather than letting the user choose their own journey, sorry.
@hughsie let's not start a discussion about what package managers are good for and what not, suffice it to say that some systems (e.g., macOS, RISC OS) use drag-and-drop instead of a package manager for user applications.
- I think that the AppStream format should not be generic enough as to not make assumptions about a package manager being used.
- Quick fact check, over >90% of the open source applications I am using have a "Download" page.
- The tag I am suggesting would be entirely optional.
The tag I am suggesting would be entirely optional
What would be the benefit to the upstream project if the tag isn't being used in any software centers?
I know at least one software center that will use it, https://github.com/AppImage/AppImageHub
Correct. Let's say "AppImageHub's demo software center", since I assume proper ones will follow soon.
Can you explain how the download URL would be used in the demo software center (that seemingly doesn't exist yet) when the entire purpose would be to distribute AppImages rather than get users to compile tarballs? I'm just not getting it, sorry.
It would simply drop the user to https://www.kdevelop.org/download where he would see which versions for which OSes are available, since AppImageHub is not aware of versions (assuming that versions keep changing faster in upstream projects than a central directory can keep up with).
Another example, https://ultimaker.com/en/products/cura-software - the author asks the user for some information before the download.
Yeah, I'm sorry, download URLs where the user has to jump through a bunch of hoops to get to what they want isn't going to fly with AppStream, it really goes against its design and the design of tools building on it.
However, if you really need it for specialized usecases, you can add this as a custom property to the custom key-value store, e.g. via appimage::download-url. That can then be queried from anything that supports this :-)