Support for appstream ID

snapcraft
,
18

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
19

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.

3 Likes
20

Reviewer tools update is now deployed to production.

1 Like
21

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.

2 Likes
22

FYI I’ve started looking at the snapd side of things.

1 Like
23

PR to snapd is open for reviews right here:
https://github.com/snapcore/snapd/pull/5199

24

afaict it seems snapcraft doesn’t prevent multiple apps in the same snapcraft.yaml to have/repeat the same common-id, is that intended?

25

@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.

26

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?

27

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

28

@sergiusens @pedronis I suggest rejecting it for now. It’s easier to allow it later than to reject it later.

29

review-tools should also check for this then, cc @jdstrand

30

Shall I check for duplicate common-ids in snap pack --check-skeleton then?

31

Yeah, certainly sounds reasonable.

32

The review-tools don’t do this, but certainly can. I’ll adjust.

1 Like
33

This is committed to master and will be in production hopefully next week.

1 Like
34

The snapd piece of the puzzle has just landed.

35

In 2.33 (out 11th June) or in master (presumably 2.34)?
Oh, jdstrand’s post implies master (2.34) my bad?

36

I have deployed that new version of the click reviewers tools to the production store; snaps with multiple repeated common-ids will now be flagged.

37

Support landed in snapd-glib 1.41.