<provides/> tag, distributors must also ensure that the package providing the file contain 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/appdata/%{id}.metainfo.xml, where id is a unique identifier of this specific component.
Note
/usr/share/appdata/%{id}.appdata.xml.
/usr/share/appdata/symbols directory is reserved for a possible future use for storing upstream-generated symbols files for libraries.
<component>
tag as root element. The <component>
element must at least have an id, name and releases tag, a provides tag with appropriate children is highly recommended. All possible tags in the generic set are:
<id>
tag is a short and unique identifier for this component. It must contain only ASCII characters, dots, hyphens and numbers, spaces are not allowed. Specialized metainfo types, such as application or fonts, may apply additional restrictions on the id tag value.
<metadata_license/> tag is indicating the content licence that you are releasing the one Metainfo XML file as. This is not typically the same as the project licence. By ommitting the licence value would probably mean your data would not be incorporated into the distribution metadata (so this is a required tag). Permissible licence codes include:
<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. A release tag can have the properties version and timestamp which contain the version number and a release timestamp in form of a UNIX epoch.
<releases> <release version="1.2" timestamp="1397253600" /> <release version="1.0" timestamp="1345932000" /> </releases>
provides tag and it's 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 it's 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.
Linux Libertine O. The tag must have a file property stating the filename of the referenced font.
<provides> <font file="LinLibertine_R.otf">Linux Libertine O</font> </provides>
<provides> <firmware>ipw2200-bss.fw</firmware> </provides>
type property of this tag. Allowed values are session 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:
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 application's primary screenshot. Every <screenshot/> tag must have at least one <image/> child, which should define the width and height of the referenced image in it's properties. The value of the <image/> tag is a direct URL to a screenshot uploaded to a public location on the web.
<screenshot/> tag may have a <caption/> child, defining a short (not more then 255 characters!) description of what the user can see on the referenced screenshot.
<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>
<?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</metadata_license> <provides> <library>libfoobar.so.2</library> <font>foo.ttf</font> <binary>foobar</binary> </provides> <releases> <release version="1.2" timestamp="1365768000" /> </releases> <developer_name>FooBar Team</developer_name> </component>