Support for appstream ID

#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:

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