# Services

## Introduction

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 ). 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`.

## File specification

The basic structure for a generic component as described at 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 .

<id/>

  For services, the `<id/>` tag value must follow the AppStream ID naming conventions (it should be a reverse-DNS name).

<metadata_license/>

  The `<metadata_license/>` tag as described in must be present.

<name/>

  A `name` must be present for services. See for a detailed description of this tag.

<summary/>

  A `summary` must be present for services. See for a detailed description of this tag.

<provides/> ↪ <service/>

  This tag is described in detail for generic components at .

<launchable/>

  This tag is described in detail for generic components at .

  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: , , , , .