[AppStream] Appstream ID and Flatpak

[Alexander Larsson]

What exactly does this mean:

```
<component type="desktop-application">
  <id>org.example.FooBar</id>
  <launchable type="desktop-id">foobar.desktop</launchable>
  <provides>
    <id>foobar.desktop</id>
  </provides>
  ...
</component>
```

Suppose the upstream app has a foobar.desktop file (with corresponding
id=foobar.desktop in the appdata file).
We need the shipped desktop file with the app to be
org.example.FooBar.desktop, and the appdata file must find that file when
for the extra info. What should we put in the modified appdata file?

Also, the actual renaming of the appdata file should not be a problem
right? We do that so the tooling finds it in a well-known path, the issue
is only the id listed in the xml.


On Tue, Dec 12, 2017 at 1:15 AM, Matthias Klumpp <matthias at tenstral.net>
wrote:

> 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
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20171212/b203c5a2/attachment.html>