I'm maintaining the Picard Flatpak over at Flathub. (and by the way, if anybody in the core team wants access to that, do let me know and I'll happily give you the keys 
)
Flatpak enforces a naming convention for desktop app resources, based around the "application ID".
That application ID needs to be a valid DBus well-known bus name. That is, a "reverse DNS"-style name.
And then all the public resources of the app must be named after that application ID:
- the desktop file
- the appdata file (see #1384)
- the app icons (the ones used to identify the app in desktop menus, not the UI icons used in the app)
- the name taken by the app on DBus
Before Flatpak, it was merely a convention to use the same name for all these things. A convention which wasn't followed much, and it didn't really matter.
Flatpak enforces this convention, because it allows some automatic integration into the desktop:
- appdata, desktop and icon files named with the app id are "exported" so that they are visible in the desktop launcher menus and software center;
- DBus access is automatically authorized, and an app can't impersonate another one on the bus;
Picard currently doesn't follow this convention, so the Flatpak build of Picard I maintain has to rename the icons and desktop file.
When I flatpaked Picard, I chose "org.musicbrainz.Picard" as the app id, because, well, Picard is hosted at https://picard.musicbrainz.org.
One problem is that software centers like KDE Discover or GNOME Software now see a duplicate:
- the "picard" package coming from the distro;
- the "org.musicbrainz.Picard" Flatpak coming from Flathub;
Those software centers have no way to understand that they are in fact the same app, and so confused users are presented with both.
This issue is a request for you to change the application ID so it matches the naming convention. This way, both distro packages and Flatpak builds will use the same naming, and software centers will be able to deduplicate the various builds.
It also means I will be able to stop renaming the files in the Flatpak build, which is always nice. 
I'm not set on the "org.musicbrainz.Picard" name, if you prefer something else. I do feel it fits Picard quite well though.
Also, if you agree to doing this, I'll be happy to send the pull request myself.
- is related to
-
PICARD-1384 Add AppStream data
-
- Closed
-
[PICARD-1393] Change the application ID
This is not fixed, as the icons haven't been renamed yet.
Picard doesn't seem to take a name on the session bus, so there's nothing to do related to that.
Grepping through the source, I don't think there's anything else to rename except for the icons.
We will handle this as part of https://github.com/metabrainz/picard/pull/1020
Sorry, I forgot one piece of context…
Currently, the application ID for Picard, upstream, is simply "picard".
That's basically the name of these public resource files: picard.desktop, picard.png, etc…
What I'm suggesting is renaming all these files to follow a DBus-/Flatpak-compatible naming, one possibility being org.musicbrainz.Picard.
Is that clearer?
> lack of knowledge about how software centers actually deduplicate things.
They use the app id in the appstream file. Appstream is repository metadata, which aggregates the appdata for each app in a given repository.
Two apps in two different repositories with the same app id will be deduplicated.
> Would fixing PICARD-1384 automatically fix this (assuming the appstream data file kept the existing "org.musicbrainz.Picard" application id)?
Not really, no.
Fixing PICARD-1384 with an appdata named org.musicbrainz.Picard.appdata.xml means the appdata will use "org.musicbrainz.Picard" as its app id, but the rest (desktop file, icons, …) will still use "picard" as app id.
The inconsistency can in fact cause problems: the appstream for a repository is built by appstream-glib, which will take informations from the appdata and desktop files. Therefore it is crucial that appstream-glib can associate the appdata and desktop file.
The easiest way to make that association is to name them both ${appid}.appdata.xml and ${appid}.desktop.
—
I hope this is all clearer now.
Maybe I should just submit a pull request, to show what it all entail?
I don't understand this ticket, mainly because I'm not aware of Picard having chosen an application id and lack of knowledge about how software centers actually deduplicate things.
Would fixing PICARD-1384 automatically fix this (assuming the appstream data file kept the existing "org.musicbrainz.Picard" application id)?
> Nobody said this has been fixed, , we are still reviewing the PR.
Ah sorry, I misunderstood the "Fix for" field when I received the email it had been set.
Now I understand you set it in advance as the desired target for the fix, not as the actual release where it's been fixed once the PR is merged.
But since it's merged now, it's all moot anyway.
Thanks for taking care of that, it's a big hurdle that gets removed for Flatpak and software centers.
I really should have sent it upstream myself long ago, back when I flatpaked Picard. Sorry again for that.
Now to wait for 2.1.0!