Created attachment 136073 [details] SCreen recording When I browse or search for "Godot", I see two Godot Engine entries: one for the Flatpak version, and one for the PackageKit-provided version. But when I click on either one, the resulting page has a "sources" menu in the corner that shows the Flatpak one too! So there should not be a standalone Flatpak entry in browse and search lists, because there is already a combined, de-duplicated one. I can't reproduce the problem for any other apps present in multiple backends which are de-duplicated on their app page. It only seems to happen for Godot Engine. $appstreamcli search godot Identifier: org.godotengine.Godot [desktop-application] Name: Godot Engine Summary: Multi-platform 2D and 3D game engine with a feature-rich editor Package: godot Homepage: https://godotengine.org Icon: org.godotengine.Godot.png
*** Bug 435607 has been marked as a duplicate of this bug. ***
I think I see the issue: $ appstreamcli search godot Identifier: org.godotengine.Godot.desktop [desktop-application] Name: Godot Summary: Godot game engine editor Bundle: flatpak:app/org.godotengine.Godot/x86_64/beta Homepage: https://godotengine.org/ Icon: org.godotengine.Godot.png --- Identifier: org.godotengine.Godot.desktop [desktop-application] Name: Godot Summary: Godot game engine editor Bundle: flatpak:app/org.godotengine.Godot/x86_64/stable Homepage: https://godotengine.org/ Icon: org.godotengine.Godot.png --- Identifier: org.godotengine.Godot [desktop-application] Name: Godot Engine Summary: Multi-platform 2D and 3D game engine with a feature-rich editor Package: godot Homepage: https://godotengine.org Icon: org.godotengine.Godot.png [snip] org.godotengine.Godot.desktop vs org.godotengine.Godot
I suppose this resolved itself meanwhile? If not appstreamcli dumps of the two would be useful. It's my understanding that they should be deduplicated if one correctly provides the other, otherwise that'd be an issue with godot's metadata itself.
It has not gone away sadly. Now I'm no a different distro (Fedora 40 KDE, vs openSUSE Tumbleweed when I originally reported it) and it's still happening here too.
Created attachment 169492 [details] appstreamcli dump org.godotengine.Godot
Created attachment 169493 [details] appstreamcli dump org.godotengine.Godot.desktop
Clearly their appstream IDs differ (org.godotengine.Godot vs org.godotengine.Godot.desktop) but my point is that Discover is being too strict here, and should consider IDs to be matching if they differ only by the presence or absence of the ".desktop" suffix. This is an optional thing that was used for years and still accepted by the spec, so I don't think we're gaining anything here by being strict. Changing to wishlist.
Which one is the one that should be shown?
Also, why would we implement this on a discover level rather than on a libappstream level?
That one I can't answer. Maybe Matthias Klumpp can weigh in.
To make one thing super clear: This *must not* be fixed in Discover, and it also *must not* be addressed in AppStream either. No entity except for the upstream project and, in rare cases, the packager, should ever mess with the component ID. A lot of stuff is tied to it, changing is basically means renaming the project, and stripping a bunch of associated metadata. We also have pretty bad history with messing with component IDs, causing a ton of issues (so, the only place we touch them in distributions is when there is no MetaInfo file and an ID is synthesized). For the issue at hand, this is a weird one! I was looking at this using the Debian package, since that's the distro I use. On Debian, the component has the ID `org.godotengine.Godot`, so I thought maybe we rename it in the package! Turns out, that is not the case: https://salsa.debian.org/debian/godot3/-/blob/master/debian/rules?ref_type=heads#L97 So, Debian just ships the metaInfo file that upstream provides, which has the `org.godotengine.Godot` ID. So, looking at the Flatpak recipe, for some reason Flatpak does *not* use the upstream-provided MetaInfo file, but provides its own one! And look at that: https://github.com/flathub/org.godotengine.Godot/blob/master/org.godotengine.Godot.appdata.xml#L3 => It has the "wrong" ID, diverging from upstream! Funnily enough, the Flatpak itself is named `org.godotengine.Godot`, so I see no reason at all for this weird diversion... Maybe it had something to do with appstream-glib in the past before Flatpak switched to libappstream, but that would be odd... In any case, this goes completely against what MetaInfo files are designed for, upstream is supposed to provide them, and packagers may only provide one if upstream doesn't have one. So, tl;dr, this is not a Discover bug or AppStream or Flatpak bug, but a bug in the Flatpak bundle. IMHO the downstream MetaInfo file should just be deleted and the one from upstream should be used instead, that's what it's for! (and if anything is missing, just contribute the metadata upstream!) At the very least, the component ID should be harmonized with what upstream ships though.
Oh, just to add: Component IDs should be matched *exactly*, doing heuristics was a really bad idea of the past. If an application wants to rename its ID, it can do so *explicitly* by using a `replaces` block: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-replaces Of course, if such a hint is there, Discover should follow it and combine the two components under the new name (if libappstream hasn't done that already). Some components use "provides" instead of "replaces", which is a bit unfortunate (likely from a time before we had a proper replacement mechanism in AppStream...), but at least this is also explicit and no error-prone heuristics are happening. If any duplicate apps happen, those issues should be fixed by the distributors (Flathub, Debian/Fedora/OpenSUSE/Ubuntu/etc) or by the respective upstreams by either fixing the ID or by adding any missing `replaces` tags.
Thanks for the info! It looks like that appdata file was added when the app was originally packaged on Flathub 7 years ago, with no explanation. Maybe at the time the project didn't have one of its own? Today it looks like the file is largely synced with upstream, with a few changes, such as adding this disclaimer that it's not packaged by its own developer: https://github.com/flathub/org.godotengine.Godot/commit/7c83b27d616d7ac66482bddb176b2ee9dd394f41 And this disclaimer about Flatpak-specific limitations: https://github.com/flathub/org.godotengine.Godot/commit/5ad29ebe45750b8ac0d07d3f4d623abbe25934d2 So maybe all that's necessary there is changing the ID from org.godotengine.Godot.desktop to org.godotengine.Godot? Does that make sense?