<div dir="ltr">What exactly does this mean:<br><br><div>```<br> <component type="desktop-application"><br> <id>org.example.FooBar</id><br> <launchable type="desktop-id">foobar.<wbr>desktop</launchable><br> <provides><br> <id>foobar.desktop</id><br> </provides><br> ...<br> </component><br> ```</div><div><br></div><div>Suppose the upstream app has a foobar.desktop file (with corresponding id=foobar.desktop in the appdata file).<br></div><div>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?<br></div><div><br></div><div>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.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 12, 2017 at 1:15 AM, Matthias Klumpp <span dir="ltr"><<a href="mailto:matthias@tenstral.net" target="_blank">matthias@tenstral.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-12-12 1:03 GMT+01:00 Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>>:<br> > Hey,<br> > In KDE's Discover (and I'm pretty sure Gnome Software too) we rely on<br> > the appstream id to de-duplicate applications: if packagekit, flatpak<br> > or snap offer me an application, we will choose the one from the<br> > backend we prefer, rather than showing the 3 of them.<br> ><br> > This premise is broken on many flatpak applications specifically as<br> > it's more strict than distributions and doesn't allow applications to<br> > ship without the rdns id. Some applications then will workaround this<br> > requirement by renaming the appstream in the packaging [2] or by just<br> > adding the appstream information with a different name and renaming<br> > the desktop file [3].<br> ><br> > I'm not sure if this is a known issue or what's the plan here, I'd<br> > suggest as a first approach to deprecate "rename-appdata-file" from<br> > flatpak-builder manifests and push packagers to actually get upstream<br> > to do the right thing. At least this way we will have the metadata<br> > converge at some point.<br> <br> </span>I would like to add to this point that I always saw<br> "rename-appdata-file" as a means to get rid of dashes in the ID, and<br> not as a way to just give the bundled app an arbitrary component-ID.<br> This goes very much against the goals of AppStream, and I am a bit<br> unhappy that this seems to be the norm on Flathub.<br> <br> AppStream itself has facilities to ensure correct and<br> backwards-compatible naming.<br> The component-id (<id/> tag) should always be an arbitrary rDNS name<br> of the project. No further rules apply.<br> If information from a .desktop files should be imported, or the app<br> wants to be launchable from a software-center, a <launchable<br> type="desktop-id"/> tag can be added. To make it known that there was<br> an old component-ID that has been replaced, the <provides/> tag can<br> contain the old component-ID.<br> <br> Therefore, a metainfo file with these old contents:<br> ```<br> <component type="desktop-application"><br> <id>foobar.desktop</id><br> ...<br> </component><br> ```<br> <br> Can easily become a file with these contents with full backwards<br> compatibility, and without doing a Flatpak-specific rename:<br> ```<br> <component type="desktop-application"><br> <id>org.example.FooBar</id><br> <launchable type="desktop-id">foobar.<wbr>desktop</launchable><br> <provides><br> <id>foobar.desktop</id><br> </provides><br> ...<br> </component><br> ```<br> (the provides section is optional, but it e.g. helps to merge in<br> ratings & reviews from the old ID)<br> <br> The AppStream component-id is supposed to be unique for the particular<br> application and should never ever change depending on how and where<br> the application is packaged or published. That's its whole point.<br> <br> Cheers,<br> Matthias<br> <div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br> Flatpak mailing list<br> <a href="mailto:Flatpak@lists.freedesktop.org">Flatpak@lists.freedesktop.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/flatpak</a><br> </div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px">=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=</span><br style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"><span style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"> Alexander Larsson Red Hat, Inc </span><br style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"><span style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"> </span><a href="mailto:alexl@redhat.com" style="word-break:break-all;font-family:monospace;font-size:14.6667px" target="_blank">alexl@redhat.com</a><span style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"> </span><a href="mailto:alexander.larsson@gmail.com" style="word-break:break-all;font-family:monospace;font-size:14.6667px" target="_blank">alexander.larsson@gmail.com</a><span style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"> </span><br style="color:rgb(46,52,54);font-family:monospace;font-size:14.6667px"></div></div> </div>