I’m confused as to what this common_id field contains, @niemeyer can you please show how it fits into the following example?
In the Ubuntu (.deb) archive we have an entry for GNOME Calculator like this (from /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_main_dep11_Components-amd64.yml.gz):
Graphical software stores want to be able to recognise both packages are the same application, just packaged and delivered with different methods. They expect to be able to do this by matching the AppStream ID from both systems (this is done currently with .debs/.rpms and Flatpaks).
In the Snap case above, what will common_id contain?
FYI, server-side support for common-id is now available.
Next steps seems to be updating the reviewer tools to allow that field in snap.yaml (@jdstrand ), and updating snapcraft to handle it too (@sergiusens). Probably we want the reviewer tools updated first so we don’t reject revisions using the new field.
As an update, there’s only one piece missing in this story which is the integration of the store-provided common-id with snapd so that it will expose that through its API. We have this work scheduled for the current cycle and hope to finish it soon.
@pedronis No, not intended. It’s okay for multiple applications to have the same common-id, given that the snaps might be alternatives to the same piece of software, but it doesn’t make much sense for these to be in the same snap.
as we were just discussing with @niemeyer it’s probably not expected but doesn’t have a big impact on how snapd/the store use common-id, but I see code in snapcraft that seems to cross-reference common-id and desktop files which I don’t fully understand and don’t know how is affected by repeated common-ids