Add release download URLs to metainfo files?

[hsitter]

I am currently looking to replace the backend data for KDE's application overview pages. They are fairly store-ish in their nature.

One thing I always find annoyingly missing though is a display of released artifacts (source/possible binaries). When I go to such a page I rather expect some quick way to access the latest released binary so I can give it a whirl.
Seeing as the AppData already has a releases definition I was wondering if it would make sense to extend it with the ability to specify artifact URLs with a localizable description string.

Something like

​  <releases>
​    <release version="3.12.2" date="2013-04-12">
​      <description>
​        <p>Fixes issues X, Y and Z</p>
​      </description>
<artifacts>
  <artifact>
    <description>Windows Binary</description>
    <url>https://foo.com/yo-3.12.2.exe</url>
  </artifact>
</artifacts>
​    </release>
​  </releases>

and maybe a checksum?

This would make it easier to render generic software store websites (like fosshub) based on appdata.

[hughsie]

As a related thing, this is what fwupd does:

<releases>
  <release version="65795" timestamp="1507011760">
    <size type="installed">7004701</size>
    <size type="download">6730530</size>
    <location>https://fwupd.org/downloads/e997e3e3b89f6bfbd87d8401b4db0bb4359a1999-firmware.cab</location>
    <checksum filename="e997e3e3b89f6bfbd87d8401b4db0bb4359a1999-firmware.cab" target="container" type="sha1">b349baf8a456382a8d63cf0bae0178333d8e92db</checksum>
    <checksum filename="firmware.bin" target="content" type="sha1">22e65a2b57604b2c5935c16d6ae9af7f1f27a752</checksum>
  </release>
</releases>

[ximion]

Yeah... The location tag is something different though, because it is very specific to firmware at the moment.
I think a while back I rejected a similar idea to define app download locations in metainfo files, because the AppStream spec should describe what an application/component is, and never how to get it. Adding information on how to get an application is the job of a package manager ot bundling system, like Flatpak.

Something that I really don't want is a bunch of arbitrary links for release artifacts - if we would add such a thing, we should have an enum of recognized artifact types, so they can be dealt with automatically by software centers and other tools that want to deal with them.

The question is though, who would use that? Would this actually be a feature KDE Discover and GNOME Software would use, or others would find useful? If it's KDE website specific, using the <custom/> tag might be a way out.

Cc: @probonopd

[probonopd]

Not sure whether it is feasible or desired to keep track of each version in the AppStream files. I think it would be sufficient to have information in AppStream files that would allow clients to figure out, based on that information, the URL of the most recent version for a given format (source code, deb, rpm, Snap, Flatpak, AppImage,...) in a given channel (release, alpha, beta, nightly, continuous,...).

So, for example, you might want to specify:

• For the latest release (source code), go to https://foo.bar/downloads and grep for the first occurence of baz-*.tar.gz
• For the latest release (deb), go to https://foo.bar/downloads and grep for the first occurence of baz-*.deb
• For the latest release (AppImage), go to https://foo.bar/downloads and grep for the first occurence of baz-*.AppImage
• For the latest continuous build (source code), go to https://foo.bar/downloads/continuous and grep for the first occurence of baz-*.tar.gz
• ... you get the idea

Depending on the naming schemes used on the download pages, the client may need some intelligence to figure things out (e.g., for GitHub Releases, using the GitHub API).

In AppImage, we are using the concept of update information for this purpose.

[ximion]

Since we have release s now, this issue is solved, right?
It has no localizable description string, but a type (source or binary) ID and a platform specifier. I think that does take care of everything in the original request.
Feel free to reopen if there is still something you feel is missing (or better maybe, open a new report for that).