Appstream ID and Flatpak

[Aleix Pol]

On Tue, Dec 12, 2017 at 1:03 AM Aleix Pol <aleixpol at kde.org> wrote:
>
> 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.
>
> Aleix
>
> [1] https://bugs.kde.org/show_bug.cgi?id=387790
> [2] https://github.com/flathub/io.github.Hexchat/blob/master/io.github.Hexchat.json#L8
> [3] https://github.com/flathub/org.blender.Blender

Hi everyone,
I'm sorry for resurrecting this thread but this issue persists and
this only makes the problem bigger.

A way to mitigate this issue would be to include at least the
appstream id of the component from before renaming in the
appstream.xml.gz file that gets distributed by the repositories. (see
Klumpp's suggestion WRT
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-provides)

Or otherwise, we can find a smarter different way that I can't see at
the moment. But breaking the id part of appstream dilutes a lot its
appeal and proves we just have a hard time at working together.

Aleix