MetaInfo

AppStream Metadata

Introduction

These pages contain information on how KDE can make use of the MetaInfo data provided by the Freedesktop.org AppStream project.

Outline

MetaInfo files are used to describe a software component in a distribution. The metadata these XML files provide contains information about the public interfaces this component provides, the descriptions of the component, as well as additional things such as icon information and categorization. There are several special components, for example for applications, web-applications, fonts, codecs and input-methods. The information defined in these files is used by AppStream-compatible software centers (such as Apper or GNOME-Software) to display them to the user. In the following, we describe for different kinds of KDE software components how to write proper AppStream MetaInfo files. A project may ship multiple metadata definitions, for example if it ships an application and a library, or multiple applications.

Metadata Types

Attention

All metadata files follow the same XML rules and are essentially the same. The separation made on this page is solely to address different groups of people and different projects, to help them getting started quickly without reading too much information which is not relevant for the project they are developing.

Application

Applications are (usually graphical) programs which show up in the applications menu, meaning they have a .desktop-file. You can read more about how to write metadata for them on the page about desktop-apps.

Component

A generic component is a software project which doesn't fit into a specific category. This is usually a shared library or framework which wants to publish information about the public interfaces it provides in a distribution, to make it easier for developers to find the component in the distribution's repositories. You can find information on how to write metadata for a generifc component on the page about generic components.

Questions

How do I translate this data?

Scripty will extract all translatable strings and merge the translated content back into the original XML file, just like we do with .desktop files.

Why not just use the package description?

Different distros cut and join different source packages in different ways, plus, some don't offer translations.

Why not just use the DOAP description?

This is one file per-project and is not suitable when one tarball will install several applications. It's also not translatable, and it does not allow specifying information about public interfaces.

Why XML and not JSON/other?

The upstream meta-information is a subset of the AppStream distribution data schema, which is also XML.

Where will this data be used?

We will scrape this data when building and composing distributions, and depending on the implementation will either use an OCS server or directly copy the AppData data into the AppStream metadata. In distributions, this data will be used in software-centers, as well as in other tools to query the installation of missing components.

Why do the data files have two different suffixes?

The metadata files have a ".appdata.xml" suffix if the component described inside is an application (type="desktop"), while in any other case the suffix is ".metainfo.xml". Reason for that is that the metadata files should be named after the string defined in their <id/> tag, which is the basename of the .desktop-file for applications. Due to historical reasons, the .desktop-suffix is omitted in AppData files. If now a project wants to ship an application and a different component with the same name, there might be naming collisions (e.g. an application named "foo.desktop" and a component with the same name). To avoid these, only applications use the ".appdata.xml" suffix. Also, "appdata" in a way implies that there is an application described inside.

Further Information

For further reading, we suggest taking a look at the AppStream documentation and its XDG wiki page.

KDE Guidelines and HOWTOs/AppStream