Using external metadata

The order is:

  • src at the end of pull
  • build at the end of build
  • install at the end of build

Each step updates the previous one. I will encode this in the docs.

2 Likes

common-id: com.example.sampleapp

The desktop ID should end with .desktop if the docs read right
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id

No, the common-id is the ID itself, not the name of the .desktop file. The ID in appstream files is what gets matched by this attribute, and that is defined without the .desktop suffix.

@sergiusens, have I found a bug?

My snapcraft yaml (snippet):

...
adopt-info: openra
...

apps:
  cnc:
    common-id: openra-cnc.desktop
    ...

  d2k:
    common-id: openra-d2k.desktop
    ...

  ra:
    common-id: openra-ra.desktop
    ...

  cnc-server:
    ... # no common id
  d2k-server:
    ... # no common id
  ra-server:
    ... # no common id

parts:
  openra:
    parse-info:
    - usr/local/share/appdata/openra-cnc.appdata.xml
    - usr/local/share/appdata/openra-d2k.appdata.xml
    - usr/local/share/appdata/openra-ra.appdata.xml
    ...

This installs three appdata/metainfo files with the IDs of:

  1. openra-cnc.desktop
  2. openra-d2k.desktop
  3. openra-ra.desktop

When I run snapcraft I am returned the following warnings:

...
Priming openra 
The 'description' and 'summary' properties are specified in adopted info as well as the YAML: taking the properties from the YAML
Common ID None specified in app 'ra-server' is not used in any metadata file.
Common ID None specified in app 'd2k-server' is not used in any metadata file.
Common ID 'openra-d2k.desktop' specified in app 'd2k' is not used in any metadata file.
Common ID 'openra-cnc.desktop' specified in app 'cnc' is not used in any metadata file.
Common ID None specified in app 'cnc-server' is not used in any metadata file.
Snapping 'openra' |                                                
Snapped openra_release-20190314_amd64.snap

Note how it seems it only matched the last entry in parse-info against the common-ids that I have set on each of the three apps. This seemingly means that the cnc and d2k apps aren’t matched against their respective appdata/metainfo files.

This might indeed be a bug as we do not support multiple common-ids as most of the time there was supposed to be on appstream entry per snap as was the assumption made in 2017 when we started this. We will need to dedicate cycles to get this working.

The common-id property should match the id specified in the AppStream metadata file. The .desktop suffix is optional in that file, so it depends on the AppStream metadata file whether you should include the .desktop suffix in common-id or not.

Forgive my asking some fairly simple questions as I want to clarify some of this stuff for Snapcraft 101 course, so we’ll start simple with this example from earlier on in the page:

Individual parts in your snapcraft.yaml can set the version and grade by using snapcraftctl. All you need to do is select which part to adopt using adopt-info:

# ...
adopt-info: my-part
# ...
parts:
  my-part:
    # ...
    override-pull: |
      snapcraftctl pull
      snapcraftctl set-version "my-version"
      snapcraftctl set-grade "devel"

Fair enough, but since version and grade metadata are global to the snap, it seems odd that you would select just one of the snap’s parts to define that metadata; even more odd that that’s being done in just one scriptlet in that part.

What’s the rationale here? Why, in the above, was it decided that it would be the override-pull step of the my-part part that would define that metadata?

you typically only have one part that carries the main bit of your snapped app … i.e. a webapp that ships ngnix and mariadb inside will surely still want to grab the latest git tag of the webapp tree and not either of the webserver or db parts as input for your version string …

same goes for a Qt6 app on with a core20 base … you’d not take the version from the part where you build Qt6 from source, but rather the version of the app as your base for your snap versioning …

if you dont want to use either of the parts you can indeed omit all this stuff and blantly set a version: field in the toplevel metadata …

I have a question/suggestion of improvement about this. There is a way, or shouldn’t be, to the name parameter in the AppData XML file populates the “title” field of snapcraft.yaml? I just published a Snap called “getting-things-gnome” (that’s the name in the snapcraft.yaml). But the beautified name is “Getting Things GNOME!” (that’s the name in AppData XML file). The beautified name should be the autopopulated title of Snap, but instead the Snap got (in the first time I published in the store) “getting-things-gnome” as name and title. I had to edit the title manually in the Snap store. What do you think?

2 Likes

This page doesn’t cover the “craftctl set” syntax of snapcraft 7.

Echoing Rob’s comment above; @sergiusens @degville – It may be nice to have this page be linked to from this page which is present in the sidebar and was the first link I clicked on to see how to set the grade dynamically for base: core20 snaps.

Thanks for this great suggestion, @dilyn. I’ve added a link, but I’ve also added a link to this doc in the navigation too.

1 Like