+1, given that this is specific for ‘appstream’, which we want to support, and AFAICT there isn’t any other ID system ATM for apps, I’d name it something like appstream_id (instead of a more generic/complex field or something requiring to guess the ID format).
@niemeyer, thoughts?
The earlier suggestion of going with “common-id” still seems like the correct path.
The main rationale for not labeling it as “appstream-id” is that this is a snap specification, not an appstream specification, so the field name needs to convey the meaning inside a snap context. People can put this field to good use without ever touching an appstream file or ever using the ID in that context.
In the snap end, the field is also not required, and it does not sound sensible to enforce uniqueness in the store for at least two reasons. The most important one is that it would go against the very point of having the field in the first place. The single reason we are adding this is because one may have multiple alternatives for the same application. Why would we be okay with having multiple alternatives for the same app, but only if they come in from different stores? This may sound sensible in a world where everybody can have their own small repositories, but in the snap world everybody is collaborating around a single universal repository. We want these alternatives to be able to coexist there.
The second reason is that if we do that we’ll also have to worry about conflict handling, and what to do when that happens. That’s not as trivial as it may sound. We have infrastructure today for forcing the rename of a snap if it turns out a well known name is not being used in the most expected snap (e.g. mozilla would like to publish “firefox”). If we need to support that for the common ID, we’ll need to support a snap-declaration for it as well so that we can override a name if really necessary. That’s doable, but more work both to implement and to support the feature over time (forever) as it requires arbitration.
With all that said, the documentation of the field should still mention that this field has the same purpose of the appstream ID, and that when a piece of software has both an appstream ID and a snap common-id the two ought to match.
We should also check the syntax of the value to enforce the practice used in appstream IDs today, and document it too.
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):
ID: org.gnome.Calculator.desktop
Package: gnome-calculator
Name:
C: GNOME Calculator
Summary:
C: Perform arithmetic, scientific or financial calculations
Here the ID field is the AppStream ID.
In the Snap store we have a GNOME Calculator snap with metadata (returned from a GET /v2/find request to snapd) like this:
{
"id": "J8OcDPQ0JM8dbvk29HRqpWVI9kBw0atG",
"common_id": ???,
"title": "gnome-calculator",
"summary": "GNOME Calculator",
"name": "gnome-calculator",
"type": "app",
}
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?
All the conversation above is about that.
I have read the thread and I’m trying to find an example that shows the common_id so I can better understand it.
Let me summarize a bit (I think you are confusing the snap-id per se with this common-id which is per app entry under apps).
A snap/meta.yaml will look like the following:
name: gnome-calculator
summary: GNOME calculator
...
...
apps:
gnome-calculator:
command: ...
...
common-id: org.gnome.Calculator.desktop
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.
Reviewer tools update is now deployed to production.
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.
FYI I’ve started looking at the snapd side of things.
afaict it seems snapcraft doesn’t prevent multiple apps in the same snapcraft.yaml to have/repeat the same common-id, is that intended?
@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.
Is this something we should do in snap pack or in snapcraft itself?
@pedronis do you know if the review tools already check for this condition?
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
@sergiusens @pedronis I suggest rejecting it for now. It’s easier to allow it later than to reject it later.
Shall I check for duplicate common-ids in snap pack --check-skeleton then?
Yeah, certainly sounds reasonable.
The review-tools don’t do this, but certainly can. I’ll adjust.