Define a way for websites to link to AppImage downloads

[probonopd]

Use case:
https://kde.org/applications/ shows download links for the Windows, Android... app store.
How should AppImages be represented there, and where should the information come from?

The AppStream spec allows specifying URLs to e..g, the application homepage, bugtracker, etc. - but not to, e.g., "the latest AppImage for the stable channel".

Turns out that the AppStream spec allows for custom tags:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-custom

KDE is already making use of custom tags:
https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags
cc
So the question is, do we need/want custom tags for AppImage downloads.

Requirements:

• The information in the AppStream metainfo file must not hardcode version numbers
• The information in the AppStream metainfo file should allow for multiple channels (e.g., release, nightly, alpha, beta,..)

Question:

• Do we want a "deeplink" that results in the AppImage being downloaded, or do we want a link to the download page on which the AppImage can be downloaded by the user?

Food for thought:

• Do we even need AppStream for this purpose? We could re-use AppImage update information for this purpose. This might completely remove the need for using AppStream to get this kind of information, it is already there and it already supports different channels

@jriddell: AppImage update information is a text string that is embedded within the first few KB of AppImages that support automatic updating (hopefully all of the KDE ones do!). From this string, the URL to the AppImage download can be constructed. Would that be an approach that would be acceptable for this use case, or do you think the information must come from AppStream?

[jriddell]

looking again the custom tags are only for App Stores.

For AppImage we use artifacts

      <artifacts>
        <artifact type="binary" platform="x86_64-appimage">
          <location>https://download.kde.org/stable/krita/4.3.0/krita-4.3.0-x86_64.appimage</location>
          <checksum type="sha256">488a6c27876612fca710609483a265821c6bb802d24edf1e970a544744f1c75d</checksum>
          <size type="download">210276392</size>
          <bundle type="appimage">krita-4.3.0</bundle>
        </artifact>

[probonopd]

That's a valid way to do it of course, and gets the job done for the purpose of this ticket.
However, for users who have downloaded krita-4.3.0 it doesn't really help with information on where to get the latest one...

[probonopd]

As for the graphical presentation, it would be nice to add

https://docs.appimage.org/packaging-guide/distribution.html#download-as-an-appimage-banner

to

[jriddell]

I agree on the presentation, added to our workboard https://phabricator.kde.org/T13581

[probonopd]

To add complexity, the AppStream spec states:

<bundle/>
The optional bundle tag indicates that the described software is available as a software bundle via a 3rd-party application installer. The value of this tag is an identification string for the bundle.

Software centers may use the information of this tag to offer the user to install the software from 3rd-party sources, or just update an already installed software automatically via the normal update procedure. The bundle tag can coexist with the pkgname tag, in case a component is available from multiple sources.

The type property of this tag indicates which 3rd-party software installation solution the bundle belongs to. Currently supported solutions are:

(...)
AppImageKit bundles, using the value appimage.

<bundle type="limba">foobar-1.0.2</bundle>

But it does not really specify what needs to go into the <bundle type="appimage"> tag...

cc @kossebau

[probonopd]

Some KDE projects have started to use it like this:

      <artifacts>
        <artifact type="binary" platform="x86_64-appimage">
          <location>https://download.kde.org/stable/krita/4.3.0/krita-4.3.0-x86_64.appimage</location>
          <checksum type="sha256">488a6c27876612fca710609483a265821c6bb802d24edf1e970a544744f1c75d</checksum>
          <size type="download">210276392</size>
          <bundle type="appimage">krita-4.3.0</bundle>
        </artifact>
      <artifacts>

Is this the correct way to do this?

cc @ximion

[probonopd]

Personally, I would love to see some notion of different "channels" in AppStream. Something like:

  <channels>
    <Release>...</Release>
    <Beta>...</Beta>
    <Continuous>...</Continuous>
  </channels>

The actual channels should be able to be defined by the application, e.g., for Firefox it might contain ESR:

  <channels>
    <Release>...</Release>
    <ESR>...</ESR>
    <Beta>...</Beta>
  </channels>

With the ... containing a description for how to get the latest version from that channel, without actually hardcoding a version there.

Not just for AppImage, but for all delivery formats.

So that we get a 3-dimensional matrix of OSes (Windows, Mac, Linux, Android,...), delivery formats (deb/rpm, Snap, Flatpak, AppImage, Google Play, F-Droid,...), and channels (Release, Beta, ESR,...).

Maybe architecture (aarch64, arm64,...) as yet another dimension.

But I guess that is just wishful thinking on my part...

(The way AppImageUpdate works is that release builds always update to release builds, continuous builds always update to continuous builds, and so on.)

[probonopd]

@jriddell this is something that might be worthwhile to consider for the KDE application pages too:

If I want to get Open Source software on Android, I'd always want to get it from F-Droid rather than from Google Play (in fact, I have stopped Google Play and all other stores where you need an account to log in).

So I think when one clicks on one of the OSes one should be given the various options for "delivery formats" (Google Play, F-Droid, direct download link to the .apk... for Android). Likewise for the Mac (App Store, MacPorts, direct download link to the .dmg) and for Linux.

[ximion]

Some KDE projects have started to use it like this:

      <artifacts>
        <artifact type="binary" platform="x86_64-appimage">
          <location>https://download.kde.org/stable/krita/4.3.0/krita-4.3.0-x86_64.appimage</location>
          <checksum type="sha256">488a6c27876612fca710609483a265821c6bb802d24edf1e970a544744f1c75d</checksum>
          <size type="download">210276392</size>
          <bundle type="appimage">krita-4.3.0</bundle>
        </artifact>
      <artifacts>

Is this the correct way to do this?

cc @ximion

No - using "bundle" is not allowed in an artifact tag (I wonder why that doesn't throw a validator error) and "x86_64-appimage" is not a valid normalized GNU triplet or platform name like "win32". Maybe I can validate the "platform" string at least a little bit in future (it's quite a bit more freeform, due to things like "win32" being allowed values).

Embedding the bundling system here may make sense though, like:

      <artifacts>
        <artifact type="binary" bundle="appimage" platform="x86_64-linux-gnu">
          <location>https://download.kde.org/stable/krita/4.3.0/krita-4.3.0-x86_64.appimage</location>
          <checksum type="sha256">488a6c27876612fca710609483a265821c6bb802d24edf1e970a544744f1c75d</checksum>
          <size type="download">210276392</size>
        </artifact>
      <artifacts>

The bundle tag exclusively applies to software collections, mapping an AppStream ID onto another ID used by the bundling system. You would very rarely use it directly, and even rarer use it in a metainfo file.

[ximion]

"channels" don't really exist in AppStream, that's an implementation detail of a bundling system. Releases can be marked as "development" and "stable" though, which can be mapped to a developer-snapshot and release channel.
Relevant documentation: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases