https://bugs.kde.org/show_bug.cgi?id=433463

Matthias K. <matth...@tenstral.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matth...@tenstral.net

--- Comment #11 from Matthias K. <matth...@tenstral.net> ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to