A service component is any software that is started and supervised by the Operating Systems "init" facility, such as systemd.
The metadata described in this document is built upon the generic component metadata with fields specific for services (see Section 2.1, “Generic Component”).
All tags valid for a generic component are valid for a service
component as well.
In order to enhance the available metadata about their services, projects shipping a service can ship one or more metainfo files
in /usr/share/metainfo/%{id}.metainfo.xml
.
The basic structure for a generic component as described at Section 2.1.3, “XML Specification” applies.
Note that the XML root must have the type
property set to service
, while in a generic component this
property can be omitted. This clearly identified this metainfo document as describing a service.
The following list describes tags for service
upstream metadata and provides some additional information about the values
the tags are expected to have.
If no information is given about a tag, refer to the respective tag in Section 2.1, “Generic Component”.
For services, the <id/>
tag value must follow the AppStream ID naming conventions (it should be a reverse-DNS name).
The <metadata_license/>
tag as described in <metadata_license/> must be present.
A name
must be present for services. See <name/> for a detailed description of this tag.
A summary
must be present for services. See <summary/> for a detailed description of this tag.
This tag is described in detail for generic components at <launchable/>.
At least one launchable element with type "service" must be present. The value is a name that can be used with the OS init facility to start/stop and monitor the service.
For a component of type service
, the following tags are required and must always be present: <id/>,
<metadata_license/>, <name/>, <summary/>.