This field identifies the file as DEP-11 file. Its value is always DEP-11.

The version of the AppStream specification this file was built for.

Defines the repository-id this file belongs to. This usually matches the filename without extension. On Debian systems, it is the <suite>-<component> combination, e.g.

.

The base URL for media (screenshots, icons, ...) referenced in the metadata file. If this is set, all urls in the document referencing media will be treated relative to the base url.

Defines the architecture this data belongs to. This information is useful to resolve AppStream-ID conflicts on multiarch systems, which appear if the user has metadata for two architectures installed.

The priorization of this metadata file over other metadata.

The ID field is a short unique and usually lower-cases identifier for the component. Depending on the component's type, different naming conventions apply.

See <id/>.

The Priority field sets the priority this component's metadata should have over other meadata in the pool. Data with a higher priority replaces data with a lower priority.

See Section 3.1.4, “Valid tags for all component types”.

The type of this component. Allowed values are:

The optional Merge field describes the merge strategy that should be applied when merging data of this component into its base. It may assume the values append, replace or remove-component.

See Section 3.1.4, “Valid tags for all component types” for a description on how merging works.

The name of the package which needs to be installed in order to make this component available on the system.

See <pkgname/>.

See <source_pkgname/>.

See <name/>.

See <summary/>.

See <project_license/>.

See <description/>.

The markup for the description is the same as in the XML specification, so it can be read by anything parsing basic HTML markup.

See <url/>.

The Url field contains the different url types as keys in its dict. Valid url types are defined in the main AppStream XML specification. All URL types must be lowercased.

Example:

Url:
  homepage: https://example.org
  faq: https://example.org/faq
  bugtracker: https://bugs.example.org/report-issue

See <project_group/>.

See <icon/>.

The Icon field has the different icon types as keys for its dict.

See <categories/>.

This field follows its XML counterpart in almost all regards. The different XDG menu category names are encoded in the list, and are of type str.

Example:

Categories:
  - Network
  - Telephony

See <keywords/>.

This field contains the keywords for this component. The keys define the locales for the respective language, the values are of type list and contain the list of keywords for the respective language. An unlocalized C key must be present.

Example:

Keywords:
  C:
    - IDE
    - development
    - programming
  de:
    - IDE
    - entwicklung
    - programmierung

See <screenshots/>.

The Screenshots field contains a list of screenshots. A screenshot is of type dict and contains the following keys:

Example for a Screenshots field containing one screenshot:

Screenshots:
  - default: true
    caption:
      C: Foobar showing kitchen-sink functionality
      si: Foobar shoeewing kischän-sünk funzionality
    source-image:
      height: 800
      url: https://www.example.org/en_US/main.png
      width: 600
    thumbnails:
      - height: 423
        width: 752
        url: https://www.example.org/en_US/main-large.png
      - height: 63
        width: 112
        url: https://www.example.org/en_US/main-small.png
  - source-video:
      container: matroska
      codec: av1
      height: 900
      url: https://www.example.org/en_US/screencast.mkv
      width: 1600

See <compulsory_for_desktop/>.

See <provides/>.

The Provides field is of type dict and can have the following keys set with the described allowed values:

See <developer_name/>.

See <launchable/>.

A dictionary containing the launchable-type as key, and a list of IDs used for launching the application as value.

Example:

Launchable:
  desktop-id:
    - org.gnome.Sysprof2.desktop

See <releases/>.

The Releases contains a list of releases sorted latest-to-oldest, where each list items contains the following fields/keys:

It is recommended to order this list starting with the latest timestamp to the oldest one.

Example:

Releases:
  - version: '1.8'
    unix-timestamp: 1424116753
    description:
      C: |
        <p>This stable release fixes the following bug:</p>
        <ul>
          <li>CPU no longer overheats when you hold down spacebar</li>
        </ul>
  - version: '1.2'
    unix-timestamp: 1397253600
  - version: '1.0'
    unix-timestamp: 1345932000

See <languages/>.

The languages list is a list of dictionaries. They must contain a percentage key, indicating the completion of translation for this language, and a locale key, with the locale string as value.

Example:

Languages:
  - locale: gu
    percentage: 96
  - locale: ca@valencia
    percentage: 94
  - locale: de
    percentage: 91
  - locale: eo
    percentage: 93

See <bundle/>.

The Bundles contains a list of dictionaries with the keys type, having the ID for a specific bundling system (e.g. flatpak or limba) as value, and id for the associated bundle-id. See the XML tag description for information on all valid bundling systems.

Example:

Bundles:
  - type: limba
    id: foobar-1.0.2

See <extends/>.

Contains a list of AppStream IDs of the other component extended by the described component. This field may only be used with component-type addon.

See <suggests/>.

A list of dictionaries containing suggested software components. The dictionaries must have a type key with the string value upstream or heuristic depending on where the suggestion originates from. The also must have a ids key containing a list of component-ids of the suggested software.

Example:

Suggests:
  - type: upstream
    ids:
      - org.example.Awesome
  - type: heuristic
    ids:
      - org.example.Test1
      - org.example.Test2

See <content_rating/>.

A dictionary containing the rating system as key, and a dictionary of rating-values as value. The value-dictionary itself has the content rating IDs as keys and the intensity values as values. The intensity values as well as IDs and rating system names match the values from the XML exactly.

Example:

ContentRating:
  oars-1.0:
    drugs-alcohol: moderate
    language-humor: mild

See <requires/>, <recommends/> & <supports/>.

A list of dictionaries containing the referenced items. The dictionaries in the list must have one key denoting the item type, which has the respective item value as value. Refer to the XML description for a list of possible types.

Each dictionary may have a version field with contains a version comparison string. The first two characters denote the version comparison operation, and are followed by the version number to be compared with. The comparison operation may be one of:

Example:

Recommends:
- memory: '2500'
- modalias: usb:v1130p0202d*
Requires:
- kernel: Linux
  version: '>= 4.15'
- id: org.example.TestDependency
  version: == 1.2

See <agreement/>.

A list containing the agreements as dictionaries, with a sections key containing a list of sections. All dict values are the same as the respective XML tag values / properties.

Example:

Agreements:
- type: eula
  version_id: 1.2.3a
  sections:
  - type: intro
    name:
      C: Intro\n"
    description:
      C: >-
        <p>If it breaks, you get to keep both pieces.</p>

See <tags/>.

Example:

Tags:
- namespace: lvfs
  tag: vendor-2021q1
- namespace: plasma
  tag: featured

See <custom/>.