<provides/>
tag, distributors must also ensure that the package providing the file contains all items referenced by that statement, or is installed by a metapackage depending on packages which provide these items. This gives upstream projects a (very light) way to influence distributor packaging. More information about that can be found below.
/usr/share/metainfo/%{id}.metainfo.xml
, where id
is a unique identifier of this specific component.
Note
/usr/share/metainfo/%{id}.appdata.xml
.
Legacy Path
/usr/share/appdata/
path must be scanned by AppStream tools as well, to support legacy applications installing metadata there. For new software components, it is advised not to use this directory.
<component>
tag as the root element. The <component>
element must at least have an id
, name
and releases
tag; and a provides
tag with appropriate children is highly recommended. All possible tags in the generic set are:
<id>
tag is a unique identifier for this component. It must contain only ASCII characters, dots, hyphens and numbers. Spaces are not allowed.
{tld}.{vendor}.{product}
, for example org.kde.gwenview
or com.hugski.ColorHug2
. Ownership of {vendor}.{tld}
in the domain name system guarantees uniqueness of IDs.
com.hugski.ColorHug2
for the client tools to control hardware, and com.hugski.ColorHug2.firmware
for the runtime firmware files.
<metadata_license/>
tag indicates the content license that you are releasing the one Metainfo XML file under. This is typically not the same as the project license. Omitting the license value can result in your data not being incorporated into the distribution metadata (so this is a required tag).
CC0-1.0
CC-BY-3.0
CC-BY-SA-3.0
GFDL-1.3
MIT
FSFAP
CC-BY-SA-3.0
corresponds to the license at creativecommons.org/licenses/by-sa/3.0.
p
), ordered list (ol
) and unordered list (ul
) are supported at this time.
<p/>
child has a language property.
<releases>
tag contains <release/>
child tags which describe some metainformation about the current release of the described software. The <release/>
tag may be present multiple times (for older releases), but a tag for the current version must always be present.
release
tag can have the properties version
, date
and timestamp
. The date
property can have any time in ISO 8601 format as its value and should be present for every release. The timestamp
tag contains the release time in the form of a UNIX epoch. This tag should not be used in metainfo files in newly written metadata, but will still be parsed in case it is present. The the timestamp
property is mainly used in generated distro-metadata. In case both release-time tags are present, the timestamp
tag will take precedence over date
.
<release/>
tag may also have an urgency
property, having one of the following values:
low
medium
high
critical
urgency
defines how important it is to install the new release as an update. This is especially important for type=firmware
components. If no urgency is defined, a medium
urgency is implicitly assumed. The urgency defines how the update will be presented to the user, and sometimes if it will be installed automatically and immediately, or delayed.
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/>.
release
tag may also have one or multiple size
tags as children, which define the installed and download size of this component release. This is useful in case the component does not have a corresponding native package in a distribution, for example if it is a Limba bundle or LVFS firmware. The size type is defined via a type
property on the size
tag, and may assume the value download
or installed
. The size itself is set as the value and must be given in bytes.
<releases> <release version="1.2" date="2014-04-12" urgency="high"> <size type="download">12345678</size> <size type="installed">42424242</size> </release> <release version="1.0" date="2012-08-26" /> </releases>
provides
tag and its children describe the public interfaces this application provides. A public interface can be anything which other applications, which are not part of the upstream project, can access or reference. This includes binaries and libraries. Private interfaces should never be added to a provides
tag.
provides
tag contain a number of children describing the type and name of the provided public interface items. It is suggested that the build system auto-generates this tag and its children. Currently allowed item types are listed below. If you miss something, file a bug against AppStream so we can add the new type.
/usr/lib
, /usr/lib/<triplet>
or /lib
. For example, for the libappstream library, the value for library
would be libappstream.so.1
.
PATH
.
Dustismo_Roman.ttf
.
<provides> <font>LinLibertine_R.otf</font> </provides>
firmware
component type, where it is mandatory. Please see <provides/> ↪ <firmware/> for more information.
type
property of this tag. Allowed values are user
and system
.
<provides> <dbus type="system">org.freedesktop.PackageKit</dbus> </provides>
<mimetype/>
children, describing the MIME types this application supports. This tag is especially useful for generic components and addon-type components. For applications, the metadata will automatically be fetched from their .desktop
files by the distribution's metadata generator. Example:
<mimetypes> <mimetype>text/html</mimetype> <mimetype>image/jpeg</mimetype> <mimetype>application/rss+xml</mimetype> </mimetypes>
<project_group/>
tag then this identifies your project with a specific upstream umbrella project. Known values include GNOME
, KDE
, XFCE
, MATE
and LXDE
, although other umbrella projects like Yorba or Mozilla make sense too.
Note
<project_license/>
tag is indicating the license of the component (application/library/addon/font/etc.) described in the metadata document. It should be a string in SPDX format. Licenses may be combined using and and or logic. Possible values include:
GPL-2.0
LGPL-3.0+ and GPL-3.0+
MIT
CC-BY-SA-2.0
project_license
tag is not mandatory, it is recommended to include it.
<developer_name/>
tag is designed to represent the developers or project responsible for development of the project described in the metadata.
<screenshots/>
tag contains multiple <screenshot/>
children, where at least one of them must have the property type="default"
to indicate the primary screenshot of the software. Every <screenshot/>
tag must have at least one <image/>
child.
<image/>
tag is a direct HTTP/HTTPS/FTP URL to a screenshot uploaded to a public location on the web. The <image/>
tag may have the following properties:
type
source
for the source image, and thumbnail
for a thumbnail image. In case the type is thumbnail
, the width
and height
properties must be present.
width
height
xml:lang
<screenshot/>
tag may have a translatable <caption/>
child, defining a short (ideally not more then 256 characters) description of what the user can see on the referenced screenshot.
<screenshots> <screenshot type="default"> <caption>The FooBar main window.</caption> <image type="source" width="1600" height="900">https://example.com/foobar/screenshot-1.png</image> </screenshot> <screenshot> <caption>Foobar showing the frobnicate functionality.</caption> <image type="source" width="1600" height="900">https://example.com/foobar/screenshot-2.png</image> </screenshot> </screenshots>
<update_contact/>
tag is an optional tag which can be added to provide an email address distributors can use to contact the project about invalid or incomplete metadata or – in case the specification has changed – about old metadata. It can also be used to ask general questions in case of an update of the component described in the metadata file.
<update_contact/>
tag must only be used by distributors. It is not included in the distribution-provided AppStream XML file, and therefore not exposed to the end user via any kind of UI.
_AT_
is also valid.
<update_contact>developer_AT_example.com</update_contact>
<translation/>
tag is an optional tag which can be added to specify the translation domain used for this software component. It may be used by the AppStream distro metadata generator to determine the translation status of the respective software.
type
property, assuming the value of the translation system which is used. Right now, allowed translation systems and values for type
are:
gettext
qt
<translation/>
tag may be defined more than once.
<translation type="gettext">foobar</translation>
<suggests/>
tag is an optional tag which can be added to specify the component-ids of other software this components suggests. Software centers might present the suggested software on the installation page of the described component.
type
property, with the value upstream
, indicating that this suggestion originates from the upstream project. If no type
property is given, upstream
is implicitly assumed as value. Metainfo files must not define other suggests
types, those are reserved for AppStream catalog XML (see <suggests/> in catalog XML).
suggests
tag must have one or more <id/>
tags as children, specifying the IDs of the suggested other software components.
<suggests> <id>org.kde.gwenview.desktop</id> <id>org.inkscape.Inkscape</id> </suggests>
<?xml version="1.0" encoding="UTF-8"?> <component> <id>foobar</id> <name>Foo Bar</name> <summary>A foo-ish bar</summary> <url type="homepage">http://www.example.org</url> <metadata_license>CC0-1.0</metadata_license> <provides> <library>libfoobar.so.2</library> <font>foo.ttf</font> <binary>foobar</binary> </provides> <releases> <release version="1.2" date="2015-02-16" /> </releases> <developer_name>FooBar Team</developer_name> </component>
generic
, the minimal amount of required tags is: <id/>, <name/>, <summary/>, <metadata_license/>.