Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
  1. 1 About AppStream
  2. 2 Upstream Metadata
  3. 3 Catalog Metadata
  4. 4 Miscellaneous
  5. 5 Metadata Quickstart
  6. 6 Data Validation
  7. 7 Manual pages
      appstreamcli 2012-2024Matthias Klumpp AppStream 26 July,2012 appstreamcli1appstreamcliHandle AppStream metadata formats and query AppStream dataappstreamcliCOMMANDDescription This manual page documents briefly the appstreamcli command. appstreamcli is a small helper tool to work with AppStream metadata and access the AppStream component index from the command-line. The AppStream component index contains a list of all available software components for your distribution, matched to their package names. It is generated using AppStream XML or Debian DEP-11 data, which is provided by your distributor. For more information about the AppStream project and the other components which are part of it, take a look at the AppStream pages at Freedesktop.org. Optionsget IDGet a component from the metadata pool by its identifier.ssearch TERMSearch the AppStream component pool for a given search term.what-provides TYPE TERM Return components which provide a given item. An item type can be specified using the TYPE parameter, a value to search for has to be supplied using the TERM parameter. Examples: Get components which handle the "text/xml" mediatype. appstreamcli what-provides mediatype "text/xml" Get component which provides the "libfoo.so.2" library. appstreamcli what-provides lib libfoo.so.2 refreshrefresh-cache Trigger a database refresh, if necessary. In case you want to force the database to be rebuilt, supply the --force flag. This command must be executed with root permission.status Display various information about the installed metadata and the metadata cache. os-info Show information about the current operating system from the metadata index. This requires the operating system to provide a operating-system component for itself. dump ID Dump the complete XML descriptions of components with the given ID that were found in the metadata pool. validate FILES Validate AppStream XML metadata for compliance with the specification. Both XML metadata types, upstream and distro XML, are handled. The format type which should be validated is determined automatically. The --pedantic flag triggers a more pedantic validation of the file, including minor and style issues in the report. validate-tree DIRECTORY Validate AppStream XML metadata found in a file-tree. This performs a standard validation of all found metadata, but also checks for additional errors, like the presence of .desktop files and validity of other additional metadata. check-license LICENSE Test a license string or license expression for validity and display details about it. This will check whether the license string is considered to be valid for AppStream, and return a non-zero exit code if it is not. The command will also display useful information like the canonical ID of a license, whether it is suitable as license for AppStream metadata, and whether the license is considered to be for Free and Open Source software or proprietary software. AppStream will consider any license as Free and Open Source that is marked as suitable by either the Free Software Foundation (FSF), Open Source Initiative (OSI) or explicit license list of the Debian Free Software Guidelines (DFSG). install ID Install a software component by its ID using the package manager or Flatpak. This resolves the AppStream component ID to an installation candidate and then calls either the native package manager or Flatpak (if available) to install the component. remove ID Uninstall a software component by its ID using the package manager or Flatpak. This will uninstall software matching the selected ID using either the native package manager or Flatpak (if available). put FILE Install a metadata file into the right directory on the current machine. compare-versionsvercmp VER1 [CMP] VER2 Compare two version numbers. If two version numbers are given as parameters, the versions will be compared and the comparison result will be printed to stdout. If a version number, a comparison operator and another version number are passed in as parameter, the result of the comparison operation will be printed to stdout, and appstreamcli will exit with a non-zero exit status in case the comparison failed. The comparison operator can be one of the following: eq - Equal tone - Not equal tolt - Less thangt - Greater thanle - Less than or equal toge - Greater than or equal tonew-template TYPE FILE Create a metainfo file template to be used by software projects. The --from-desktop option can be used to use a .desktop file as template for generating the example file. The generated files contain example entries which need to be filed in with the actual desired values by the project author. The first TYPE parameter is the name of an AppStream component type. For a complete list check out the documentation or the help output of appstreamcli for this subcommand. make-desktop-file MI_FILE DESKTOP_FILE Create a XDG desktop-entry file from a metainfo file. If the desktop-entry file specified in DESKTOP_FILE already exists, it will get extended with the new information extracted from the metainfo file. Otherwise a new file will be created. This command will use the first binary mentioned in a provides tag of the component for the Exec= field of the new desktop-entry file. If this is not the desired behavior, the --exec flag can be used to explicitly define a binary to launch. Other methods of launching the application are currently not supported. In order to generate a proper desktop-entry, this command assumes that not only the minimally required tags for an AppStream component are set, but also that it has an <icon/> tag of type "stock" to describe the stock icon that should be used as well as a <categories/> tag containing the categories the application should be placed in. news-to-metainfo NEWS_FILE MI_FILE [OUT_FILE] This command converts a NEWS file as used by many open source projects into the XML used by AppStream. Since NEWS files are free text, a lot of heuristics will be applied to get reasonable results. The converter can also read a YAML version of the AppStream release description and convert it to XML as well. If the metainfo file MI_FILE already exists, it will be augmented with the new release entries, otherwise the release entries will be written without any wrapping component. If [OUT_FILE] is specified, instead of acting on MI_FILE the changed data will be written to the particular file. If any of the output filenames is set to "-", the output will instead be written to stdout. The --format option can be used to enforce reading the input file in a specific format ("text" or "yaml") in case the format autodetection fails. The --limit option is used to limit the amount of release entries written (the newest entries will always be first). metainfo-to-news MI_FILE NEWS_FILE This command reverses the news-to-metainfo command and writes a NEWS file as text or YAML using the XML contained in a metainfo file. If NEWS_FILE is set to "-", the resulting data will be written to stdout instead of to a file. The --format option can be used to explicitly specify the output format ("yaml" or "text"). If it is not set, appstreamcli will guess which format is most suitable. convert FILE1 FILE1 Converts AppStream XML metadata into its YAML representation and vice versa. compose Composes an AppStream metadata catalog from a directory tree with metainfo files. This command is only available if the org.freedesktop.appstream.compose component is installed. See appstreamcli-compose1 for more information. --detailsPrint out more information about a found component.--no-colorDon't print colored output.--no-netDo not access the network when validating metadata. The same effect can be achieved by setting the AS_VALIDATE_NONET environment variable before running appstreamcli. --versionDisplay the version number of appstreamcliSee Alsopkcon1.AUTHOR This manual page was written by Matthias Klumpp matthias@tenstral.net. appstreamcli compose 2020-2024Matthias Klumpp AppStream 28 Aug,2020 appstreamcli compose1appstreamcli-composeCompose AppStream metadata catalog from directory treesappstreamcli composeCOMMANDDescription This manual page documents briefly the appstreamcli compose command. The appstreamcli compose tool is used to construct AppStream metadata catalogs from directory trees. The tool will also perform many related metadata generation actions, like resizing icons and screenshots and merging in data from referenced desktop-entry files as well as translation status information. Therefore, the tool provides a fast way to test how the final processed metadata for an application that is shipped to users may look like. It also provides a way to easily generate AppStream data for projects which do not need a more complex data generator like appstream-generator. In order for the appstreamcli compose command to be available, you may need to install the optional compose module for appstreamcli first. For more information about the AppStream project and the other components which are part of it, take a look at the AppStream pages at Freedesktop.org. OptionsSOURCE-DIRECTORIES A list of directories to process needs to be provided as positional parameters. Data from all directories will be combined into one output namespace. --origin NAME Set the AppStream data origin identifier. This can be a value like "debian-unstable-main" or "flathub". --result-root DIR Sets the directory where all generated output that is deployed to a user's machine is exported to. If this parameter is not set and we only have one directory to process, we use that directory as default output path. If both --data-dir and --icons-dir are set, --result-root is not necessary and no data will be written to that directory. --data-dir DIR Override the directory where the generated AppStream metadata catalog will be written to. Data will be written directly to this directory, and no supdirectories will be created (unlike when using --result-root to set an output location). --icons-dir DIR Override the directory where the cached icons are exported to. --hints-dir DIR Set a directory where hints reported generated during metadata processing are saved to. If this parameter is not set, no HTML/YAML hint reports will be saved. --media-dir DIR If set, creates a directory with media content (icons, screenshots, ...) that can be served via a webserver. The metadata will be extended to include information about these remote media. --media-baseurl URL The URL under which the contents of a directory set via --media-dir will be served. This value must be set if a media directory is created. --prefix DIR Set the default prefix that is used in the processed directories. If none is set explicitly, /usr is assumed. --print-report MODE Print the issue hints report (that gets exported as HTML and YAML document when --hints-dir was set) to the console in text form. Various print modes are supported: on-error only prints a short report if the run failed (default), short generates an abridged report that is always printed and full results in a detailed report to be printed. --no-partial-urls If set, all URLs in the generated data will be absolute and media_baseurl will not be used. This makes changing the media mirror harder without regenerating all data and is generally not recommended, to increase flexibility. --icon-policy POLICY-STRING Override the existing icon policy with a custom one. The icon policy sets how icons of different sizes should be dealt with. They can be in the icon cache only, be a remote icon in the media location or be both cached and available in the remote location. The icon-policy string is comprised of comma-separated %{size}x%{size}@%{scale}=%{state} statements. The size and scale are that of the respective icon, with the scale being allowed to be omitted if it is 1. The state can be one of remote, cached or cached-remote. By default, a policy of 48x48=cached,48x48@2=cached,64x64=cached,64x64@2=cached,128x128=cached-remote,128x128@2=cached-remote is selected. --allow-custom CUSTOM-KEY-NAMES By default, all custom entries set in MetaInfo input data are removed. This flag allows to whitelist custom keys to be propagated to the final catalog output data. The custom-key names should be provided as a comma-separated list. --components COMPONENT-IDs Set a comma-separated list of AppStream component IDs that should be considered for the generated metadata. All components that exist in the input data but are not mentioned in this list will be ignored for the generated output. --no-colorDon't print colored output.--verboseDisplay extra debugging information--versionDisplay the version number of appstreamcli composeSee Also appstreamcli1, appstream-generator1. AUTHOR This manual page was written by Matthias Klumpp matthias@tenstral.net.
  8. 8 AppStream API Reference
  9. Index
Applies to AppStream 1.0

3 Catalog Metadata

Additionally to the metainfo files shipped by upstream projects, AppStream also provides an XML and YAML format to make information about not installed software components known to the system.

This chapter documents this catalog metadata format and icon cache used on the client side.

3.1 AppStream Catalog XML

3.1.1 Introduction

AppStream catalog XML files are text files describing all available software components a software repository (usually from a Linux distributor) offers for installation. The XML files might be compressed with GZip.

3.1.2 File naming and location

The XML files must have a unique name, which is usually the distribution's name and version, combined with the name of the repository/origin. For example in Debian 8 (Jessie), the filename for the main repository component would be debian-jessie-main.xml.gz. For Fedora 20 (Heisenbug) updates it would be fedora-20-updates.xml.gz. 3rd-party repositories use a vendor name and repository-name combination, for example Ubuntu PPAs might get ppa-ubuntu12.04-username-foobar.xml.

There are two valid locations to store AppStream XML data. /usr/share/swcatalog/xml stores all AppStream data which has been installed via software packages, while /var/lib/swcatalog/xml stores application data which was downloaded by the package manager or placed there by other tools (for example, Limba). The /var/cache/swcatalog/xml location however can be used for any data that was locally generated from other sources. The XML files can either be plain files or be compressed with gzip. It is always a good idea to compress the files, because they tend to become quite large.

Important: Legacy Path

AppStream tools scan the paths /usr/share/app-info/(xml|xmls) / /var/lib/app-info/(xml|xmls) path for legacy compatibility as well. If possible, the old locations and old layouts should not be used anymore. Support for the legacy path will likely be dropped completely with a future AppStream 1.0 release.

3.1.3 General XML structure

The XML starts with a <components> tag as the root element. It has all the <component> tags of different types as children.

Data to fill the different component elements is usually taken from their Desktop files (https://standards.freedesktop.org/desktop-entry-spec/latest/) and package data. However, if an upstream project ships metainfo files (see Chapter 2, Upstream Metadata), values defined there should override data from any other source.

All child elements of the <components> element, no matter of which type they are, must at least have an id, name, summary and pkgname tag. For applications, a icon tag is also required.

The <components> root node has these properties, where the first two are required:


This property declares the AppStream spec version this file is based on (currently 0.14). The property is required.


Defines the repository ID this AppStream XML file belongs to. This usually matches the filename without extension (see the explanation on how to pick a good filename above). It is also used to associate the right cached icons with AppStream metadata. This property is required.


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. This property is optional.

3.1.4 Valid tags for all component types

These tags can be applied to every component type (application, component, font, inputmethod) which is described in the AppStream metadata.

Additionally to the type property, every <component/> tag in AppStream catalog data may have a priority property, defining the priority of this specific metadata over other metadata from different AppStream XML files (for example, from a different repository) which have the same component-id. The value of this tag is an integer, if the property is missing, a value of "0" is assumed.

In order to merge metadata, each component in catalog data may also have a merge property, assuming the values append, replace or remove-component. If the value is append, all data this component describes will be appended to data of the component with the same ID. If the value is replace the fields of the target component will be replaced with the ones present in the merge component. If the merge type is remove-component, the entore component matching the ID of the merge-component should be removed from the metadata pool. Merge-components with a higher priority take precedence. If a component has a merge property, the only tag that must be present for it is the <id/> tag, any other metadata is optional.


The <id/> tag is a short unique and usually lower-cases identifier for the component. Depending on the component's type, different naming conventions apply.


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

This tag can be defined multiple times, if a component is split across multiple packages.


The preferred way is to create metapackages containing the component metadata, and referencing them from the catalog metadata, and not to use multiple pkgname tags. They should only be used multiple times as a workaround or if there is no sensible way of creating a matching metapackage.


This optional tag is used to specify the source package the binary package this component belongs to was built from.

The tag can be used by software center applications to group components. It is otherwise useful for the distributor to assign components to a source package and to fetch additional information about a package from the web.


A human-readable name for this software.

In case of a component of type desktop-application, the application name as defined in the application's desktop file (https://standards.freedesktop.org/desktop-entry-spec/latest/) is used.


The <project_license/> tag is indicating the license of the component. It should be a SPDX license expression (https://spdx.org/specifications). A full list of recognized licenses and their identifiers can be found at the SPDX OpenSource License Registry (https://spdx.org/licenses/).

You can find more information about this tag at the metainfo description for <project_license/>.


The tag contains a short summary of the purpose and function of this component. In case the component is of type desktop, it is usually taken from a Desktop file, if the application does not ship an upstream metadata file.

For more information about this tag, take a look at the tag's definition at <summary/>.


A long description of the component. It is usually taken from the package descriptions or metainfo files, if they were provided. The description might use markup. Right now, only paragraph, ordered list and unordered list are supported. An example description element might look like this:

   Power Statistics is a program used to view historical and current battery
   information and will show programs running on your computer using power.
  <p>Example list:</p>
   <li>First item</li>
   <li>Second item</li>
  You probably only need to install this application if you are having problems
  with your laptop battery, or are trying to work out what programs are using
  significant amounts of power.

As opposed to the by-paragraph translation used in metainfo files, this tag is translated "as a whole", meaning that the <description/> tag itself has a language property and contains the translated paragraphs for the given language. This allows faster parsing of the Appstream XML file, and does not increase it's size much, as long as it is compressed.

For more information about this tag, take a look at the tag's definition at <description/>.


Defines URLs for this component. This tag can be present multiple times.

For a list of possible url types and what they are expected to do, take a look at the tag's description at <url/>.


The <project_group> tag identifies a project with a specific upstream umbrella project. Known values include GNOME, KDE, XFCE, LXDE, Mozilla and MATE, although other umbrella projects like Yorba would make sense too.


Components should only identify with an umbrella project if you use all their infrastructure and policies, for instance string freezes dates, bugtracker and source control instance.


The <icon/> tag describes the component icon. It is mostly used for GUI applications (component-type desktop-application). It can be of the type stock, cached, local, or url.

stock icons are loaded from stock. The icon name should never include any file-extension or path.

cached icons are loaded from the AppStream icon cache. The icon tag should contain the icon file name, including its extension. It must not contain a full or relative path to the icon file. This icon type may have width and height properties. If targeting a hi-DPI screen, this icon type may have a scale property.

local icons are reserved for AppStream data installed by local applications or via 3rd-party application installers. They should specify a full file path. This icon type may have width and height properties. If targeting a hi-DPI screen, this icon type may have a scale property.

remote icons loaded from a remote URL. Currently, only HTTP urls are supported. This icon type should have width and height properties. If targeting a hi-DPI screen, this icon type may have a scale property.

If specified, the scale property is defined as in the Freedesktop Icon Theme Specification (https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#definitions). It’s an integer value ≥1 indicating how many pixels in the image represent a logical pixel on the display, in each dimension. This allows icons for hi-DPI screens to be displayed at the same logical size as on lower resolution screens, but without upscaling artifacts.

Examples of the different methods to specify an icon:

<icon type="stock">gimp</icon>
<icon type="cached">firefox.png</icon>
<icon type="cached" width="128" height="128" scale="2">firefox.png</icon>
<icon type="remote" width="64" height="64">https://example.com/icons/foobar.png</icon>
<icon type="local" width="64" height="64">/usr/share/pixmaps/foobar.png</icon>

Multiple <icon/> tags might be combined for one application, for example to define a stock icon and a cached icon. Software-Centers should always prefer the stock icon, if it is available, and fall back to the other icon types if they can not find it. The libappstream library makes it easy to do that.

The AppStream library will prefer cached over local over remote icons when setting the non-stock icon for the application.


This tag can contain one or more <category> tags, describing the categories this component is located in. This tag is usually applied to components of type desktop-application, although it might be used by others later. This data is usually taken from Desktop files, a list of categories can be found in the Freedesktop menu spec (https://standards.freedesktop.org/menu-spec/latest/apa.html). Example:

Note: Deprecated Tags

The tag <appcategories> with its <appcategory> child elements is deprecated API. AppStream parsers should handle these tags just like the category tags, there is no difference except for the name.


This tag can contain one or more <keyword> tags, describing keywords for the component, to make it easier to find in a software center.

This tag behaves like the <keywords/> tag used in metainfo files, but is translated "as a whole", unlike its metainfo counterpart that has individual keywords translated. This means that the <keywords/> tag itself has a language property and contains only the translated keywords for the given language.

In case of type desktop-application components, this data is taken from .desktop files. For addon components, the upstream metadata file usually provides this tag.


<keywords xml:lang="de">

This tag can contain one or more <screenshot> tags, describing screenshots which are available for the software. A screenshot tag my have the attribute type="default", marking it as the software's default screenshot, which primarily represents it in a software center.

The screenshots tag is described for metainfo files in <screenshots/>. In catalog metadata, the tag has the exact same format as in metainfo files. The metadata generator may add an arbitrary number of resized thumbnails for image type screenshots though.

Every static-image <screenshot> is defined by several images of different sizes. All images should have their width and hight set as arguments. Also, one of the images should be marked as type="source", indicating that it is the unscaled version of the screenshot. Images of type="thumbnail" define thumbnails of the screenshot.

The metadata generator should scale the source image down to several thumbnails useful for the client to load. The recommended widths for thumbnail images are:

  • 752 (large)

  • 624 (normal)

  • 112 (small)

  • 1504 (large, HiDPI)

  • 1248 (normal, HiDPI)

  • 224 (small, HiDPI)

In order to support HiDPI screens, the thumbnails should also be available in their bigger sizes. A metadata generator should, however, never attempt to scale up a smaller image to a larger size, and just ship the smaller sizes instead. When scaling images to the respective thumbnail width, the image aspect ratio must be preserved, padding, cropping or stretching should not happen.

Optionally, a screenshot can contain a <caption> tag, describing the screenshot's caption. This is usually what the user can see on the image shown. The tag is translatable.

For <screenshot> tags that contain video elements, a catalog metadata generator may impose any restrictions to them, including completely removing them from the output, imposing filesize limits, etc. Upstream metainfo files should not rely on the videos being present and must always have a static screenhot for the software component as well.

Every image or video should have a full remote url set, usually pointing to a cache of images maintained by the repository vendor. Example:

  <screenshot type="default">
    <caption>FooBar showing kitchen-sink functionality.</caption>
    <caption xml:lang="de">FooBar beim Ausführen der Spühlbecken-Funktion.</caption>
    <image type="source" width="800" height="600">https://www.example.org/en_US/main.png</image>
    <image type="thumbnail" width="752" height="423">https://www.example.org/en_US/main-large.png</image>
    <image type="thumbnail" width="112" height="63">https://www.example.org/en_US/main-small.png</image>
    <video container="matroska" codec="av1" width="800" height="600">https://www.example.org/en_US/screencast.mkv</video>

The <compulsory_for_desktop> tag indicates that the component which the metadata belongs to is essential for the functionality of the defined desktop environment.

This tag is described in detail at <compulsory_for_desktop/>.


This tag is described in detail at Section 2.1, “Generic Component”.

Distributors and software repository vendors must ensure that all things described in this tag are present in the package referenced in the associated pkgname tag (or in dependencies of it).


The <developer/> tag as described in the specification for a generic component. See <developer/> for more information.


This tag follows the same schema as described for metainfo files in <launchable/>.


The releases tag and its release children are structured as described in Section 2.2, “Release Information”.

Each release tag may have a description tag as child, containing a brief description of what is new in the release. The description tag is structured as described in <description/>. This also applies to its translation rules.

The AppStream catalog XML generator may shorten overlong lists of releases to a smaller list, for example of 4 release tags. It may also convert ISO 8601 date properties of the metainfo file into an UNIX timestamp timestamp property. It should avoid generating metadata containing both properties on a release tag.

If a <releases/> tag in a metainfo file references an external release description, the release description should be read either from the release file provided locally, or, if possible and provided, be downloaded from the URL referenced in the component's releases tag.

Example for a valid releases tag:

  <release version="1.8" timestamp="1424116753">
      <p>This stable release fixes the following bug:</p>
        <li>CPU no longer overheats when you hold down spacebar</li>
    <size type="download">12345678</size>
    <size type="installed">42424242</size>
  <release version="1.2" timestamp="1397253600" />
  <release version="1.0" timestamp="1345932000" />

In case a <release/> tag has a <description/> tag as parameter, describing the new release briefly, distributors are encouraged to provide 2-4 <release/> release tags for every component. If no description is provided, one tag is enough.


This tag gives information about the translations a component provides, and to which extent the software is translated.

The tag is allowed to only occur once per component, and contains multiple <lang/> child nodes, which have a language code (https://www.gnu.org/software/gettext/manual/html_node/Language-Codes.html) as value. Each <lang/> node may have a percentage property, which describes the percentage value to which a component has been translated.

The language data is expected to be extracted by the AppStream XML generator, and is not provided upstream. Generators may obtain the information from processing GNU Gettext files, which should cover most translation methods.

Tag example:

  <lang percentage="96">gu</lang>
  <lang percentage="94">ca@valencia</lang>
  <lang percentage="91">de</lang>
  <lang percentage="93">eo</lang>

The optional bundle tag indicates that the described software is available as a software bundle via a 3rd-party application installer. The value of this tag is an identification string for the bundle.

Software centers may use the information of this tag to offer the user to install the software from 3rd-party sources, or just update an already installed software automatically via the normal update procedure. The bundle tag can coexist with the pkgname tag, in case a component is available from multiple sources.

The type property of this tag indicates which 3rd-party software installation solution the bundle belongs to. Currently supported solutions are:


<bundle type="limba">foobar-1.0.2</bundle>

The optional suggests tag provides suggestions of other software made by this component. It follows the same schema as described for metainfo files in <suggests/>.

Additionally to the upstream type allowed for metainfo files, the catalog data also allows a heuristic type, which is added by automatic recommendation services, and might be based on the user's preferences. It is commonly injected into existing metadata via a merge pseudo-component.


<suggests type="upstream">
<suggests type="heuristic">

This optional tag follows the same schema as described for metainfo files in <content_rating/>.


This optional tag follows the same schema as described for metainfo files in <agreement/>, with the exception of description tags in its agreement_section child tags now following the same translation rules as the toplevel <description/> tag in catalog metadata.

3.1.5 Example file

This is an example AppStream metadata file:

<?xml version="1.0"?>
<components version="0.10">
  <component type="desktop-application">
    <name lang="en_GB">Firefoux</name>
    <summary>Web browser</summary>
    <summary lang="fr_FR">Navigateur web</summary>
      <keyword lang="fr_FR">navigateur</keyword>
    <icon type="stock">web-browser</icon>
    <icon type="cached">firefox.png</icon>
    <url type="homepage">https://www.mozilla.com</url>
      <screenshot type="default">
        <image type="source" width="800" height="600">https://www.awesomedistro.example.org/en_US/firefox.desktop/main.png</image>
        <image type="thumbnail" width="200" height="150">https://www.awesomedistro.example.org/en_US/firefox.desktop/main-small.png</image>

    <summary>The PulseAudio sound server</summary>
    <url type="homepage">https://www.freedesktop.org/wiki/Software/PulseAudio/</url>
    <release version="2.0"/>
  <component type="font">
    <name>Linux Libertine</name>
    <summary>Linux Libertine Open fonts</summary>
  <!-- more components here! -->