Appstream ID and Flatpak

[Matthias Klumpp]

2017-12-12 1:03 GMT+01:00 Aleix Pol <aleixpol at kde.org>:
> Hey,
> In KDE's Discover (and I'm pretty sure Gnome Software too) we rely on
> the appstream id to de-duplicate applications: if packagekit, flatpak
> or snap offer me an application, we will choose the one from the
> backend we prefer, rather than showing the 3 of them.
>
> This premise is broken on many flatpak applications specifically as
> it's more strict than distributions and doesn't allow applications to
> ship without the rdns id. Some applications then will workaround this
> requirement by renaming the appstream in the packaging [2] or by just
> adding the appstream information with a different name and renaming
> the desktop file [3].
>
> I'm not sure if this is a known issue or what's the plan here, I'd
> suggest as a first approach to deprecate "rename-appdata-file" from
> flatpak-builder manifests and push packagers to actually get upstream
> to do the right thing. At least this way we will have the metadata
> converge at some point.

I would like to add to this point that I always saw
"rename-appdata-file" as a means to get rid of dashes in the ID, and
not as a way to just give the bundled app an arbitrary component-ID.
This goes very much against the goals of AppStream, and I am a bit
unhappy that this seems to be the norm on Flathub.

AppStream itself has facilities to ensure correct and
backwards-compatible naming.
The component-id (<id/> tag) should always be an arbitrary rDNS name
of the project. No further rules apply.
If information from a .desktop files should be imported, or the app
wants to be launchable from a software-center, a <launchable
type="desktop-id"/> tag can be added. To make it known that there was
an old component-ID that has been replaced, the <provides/> tag can
contain the old component-ID.

Therefore, a metainfo file with these old contents:
```
<component type="desktop-application">
  <id>foobar.desktop</id>
  ...
</component>
```

Can easily become a file with these contents with full backwards
compatibility, and without doing a Flatpak-specific rename:
```
<component type="desktop-application">
  <id>org.example.FooBar</id>
  <launchable type="desktop-id">foobar.desktop</launchable>
  <provides>
    <id>foobar.desktop</id>
  </provides>
  ...
</component>
```
(the provides section is optional, but it e.g. helps to merge in
ratings & reviews from the old ID)

The AppStream component-id is supposed to be unique for the particular
application and should never ever change depending on how and where
the application is packaged or published. That's its whole point.

Cheers,
    Matthias