Package and category `metadata.xml`

The metadata.xml file is used to specify additional data about a package or category.

Syntax

A metadata file follows the syntax defined in GLEP 68. The character set must be UTF-8 as specified by GLEP 31.

Concerning indentation there is no strict rule governing the style and width. However the following minimal set of rules need to be followed:

Indentation should be consistent, i.e. either spaces or tabs, but not both.
Keep the existing style when touching metadata.xml files that belong to other developers.

The following table summarizes the tags that may appear in a metadata.xml:

tag	description
`<catmetadata>`	This is the root element of the `metadata.xml` file for categories. It has no attributes. It contains a number of `<longdescription>` tags, each for a different language.
`<pkgmetadata>`	This is the root element of the `metadata.xml` file for packages. It has no attributes. The following subtags are allowed: `<maintainer>`, `<longdescription>`, `<stabilize-allarches>`, `<slots>`, `<use>`, and `<upstream>`. While all the subtags are optional, <upstream> may appear at most once.
`<maintainer>`	This tag specifies the persons and/or projects responsible for the maintenance of a package. The `type` attribute must be specified and can be either `"person"` or `"project"`. There is one required subtag: `<email>`. It has two optional subtags: `<name>` and `<description>`.
`<email>`	This contains the e-mail address of the maintainer. It is required.
`<name>`	This contains freetext with the name of the maintainer. It is optional.
`<description>`	The description tag contains a description of the maintainership, or for example a remark that someone interested can take over the maintainership. It is optional.
`<longdescription>`	This tag contains a description for a category or a package. For packages, it is used to augment the DESCRIPTION field in the ebuilds themselves. This tag has two optional subtags: `<pkg>` and `<cat>`.
`<stabilize-allarches>`	Indicates an architecture-independent package. An ebuild can be marked stable for all relevant architectures, when it has been tested on only one architecture. This tag must have empty content.
`<slots>`	This tag describes the slots of a package. It has two optional subtags: `<slot>` and `<subslots>`.
`<slot>`	This contains information for a particular slot. The `name` attribute is mandatory and specifies the name of the slot.
`<subslots>`	Describes the meaning of subslots for the whole package. This tag may appear at most once.
`<use>`	This tag contains descriptions of USE flags. This tag is optional and, if specified, has one required subtag: `<flag>`.
`<flag>`	This tag contains a description of how the named USE flag affects this package. It is required if the `<use>` tag is specified. It also requires the USE flag to be named in the `name` attribute. This tag has two optional subtags: `<pkg>` and `<cat>`.
`<upstream>`	This tag contains information about the upstream developers/project. It supports multiple optional subtags: `<maintainer>`, `<changelog>`, `<doc>`, `<bugs-to>,`, and `<remote-id>`.
`<maintainer>`	Provides information about the upstream maintainer. It requires a `<name>` subtag to be specified, supports an optional `<email>` subtag and an optional `status` attribute. Note that the `type` attribute must not be specified for upstream maintainers.
`<name>`	The name of an upstream maintainer should contain a block of text with upstream's name. This element is mandatory for an upstream maintainer and must appear exactly once.
`<email>`	The email address of an upstream maintainer. May appear only once.
`<changelog>`	Should contain a URL where the location of the upstream changelog can be found. The URL must be version independent and must point to a changelog which is only updated on new releases of the corresponding package. (This also implies that one can link to an automatically updated changelog in case of vcs snapshots only). May appear at most once.
`<doc>`	Should contain a URL where the location of the upstream documentation can be found. The link must not point to any third party documentation and must be version independent. If the documentation is available in more than one language, a lang attribute can be used which follows the same rules as the one for `<longdescription>`.
`<bugs-to>`	Should contain a place where bugs can be filed, a URL or an e-mail address prefixed with `mailto:`. May appear at most once.
`<remote-id>`	Should specify a type of package identification tracker and the identification that corresponds to the package in question. remote-id should make it easier to index information such as its Freshmeat ID or its CPAN name. It has a mandatory attribute `type` which identifies the type of upstream source.
`<pkg>`	This tag contains a valid qualified package name.
`<cat>`	This tag contains a valid category name as defined in `profiles/categories`.

There are also some attributes that can be used with these tags:

attribute	tags	description
lang	`<description>`, `<longdescription>`, `<slots>`, `<use>`, `<doc>`	In every case where a description is required, there must be at least an english description. If an additional description in another language is given, this attribute is used to specify the language used. The format is an IETF language tag as defined by the BCP 47 specification. Most often, this will be a two-character language code.
restrict	`<maintainer>`, `<longdescription>`, `<stabilize-allarches>`, `<flag>`	The restrict attribute allows one to restrict the application of certain tags to certain versions of a package. The format of the restrict attribute is that of a EAPI 0 package dependency specification (i.e. USE-conditional or slot dependendencies are not allowed). Since `<` and `>` are special characters in XML, they must be escaped using `<` and `>`.
name	`<flag>`, `<slot>`	When this attribute is required on the `<flag>` tag, it simply contains the name of the USE flag. For the `<slot>` tag, it specifies the slot name to which it applies. A slot name of `*` allows for a single `<slot>` tag to match all the slots of a package, in which case no other slot tags may be present.
status	`<maintainer>`	The upstream maintainer element has a status attribute, which is one of `"active"` or `"inactive"`. This attribute is not mandatory. The absence of it shall be interpreted as `"unknown"`. Please note that this attribute is only allowed for the `<maintainer>` subtags of the `<upstream>` element!
type	`<remote-id>`	A string identifying the type of upstream source. A list of valid strings are kept in metadata.dtd. Developers should email the gentoo-dev mailing list before using a new type value.
type	`<maintainer>`	Defines the type of the maintainer for a package. There are only two valid values: `"person"` and `"project"`. The latter denotes an official Gentoo project.

Package metadata

All packages must include a metadata.xml file which provides information about package description, maintainers, local USE flags, upstream etc.

For developers' convenience, a skeleton file is provided in the Gentoo tree with the name skel.metadata.xml. The metadata file can also be created using the app-portage/metagen tool.

Commits of package metadata files are handled by pkgdev as part of regular package maintenance.

Unless specified otherwise, the maintainer who is listed in the metadata first shall be the assignee for the bugs for that package as per GLEP 67.

Package metadata examples

In the following sections, various examples of metadata.xml are provided. These examples are based on actual package metadata files to keep things as realistic as possible. However, they may not include these files verbatim and should be taken as hypothetical examples.

Projects as maintainers

For the first example, a package maintained by a single project is presented. It is a simplified version of metadata.xml for the package app-office/libreoffice. The package maintainer is identified by the email address [email protected] with the name Gentoo Office Project as specified in the optional <name> subtag. It also provides a long package description.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
  <maintainer type="project">
    <email>[email protected]</email>
    <name>Gentoo Office Project</name>
  </maintainer>
  <longdescription>
    LibreOffice is the successor of OpenOffice.org. This ebuild
    allows you to compile it yourself. Unfortunately this compilation can
    take up to a day depending on the speed of your computer. It will
    however make a snappier LibreOffice than the binary version.
  </longdescription>
</pkgmetadata>

The email address [email protected] corresponds to the Gentoo Office Project as defined in projects.xml. This file lists all the projects in Gentoo and it is generated from the projects listing available on the Gentoo Wiki:

<project>
  <email>[email protected]</email>
  <name>Gentoo Office Project</name>
  <url>https://wiki.gentoo.org/wiki/Project:Office</url>
  <description>
    The Office project manages the office implementations
    and related packages in Gentoo.
  </description>
  <member>
    <email>[email protected]</email>
    <name>Andreas K. Hüttel</name>
    <role>member</role>
  </member>
  <member>
    <email>[email protected]</email>
    <name>Tomáš Chvátal</name>
    <role>member</role>
  </member>
</project>

Local USE flag descriptions

The second example is formed after the metadata.xml of sys-apps/portage. It lists multiple maintainers where one is a developer and the other is a project. It illustrates how local USE flag descriptions are specified and also contains an upstream element. It is also worth pointing out the use of mailto: prefix in <bugs-to> tag due to the presence of an email address as opposed to a URL. Conversely, email addresses specified in the <email> tags require no such prefix.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
  <maintainer type="person">
    <email>[email protected]</email>
    <name>Larry the Cow</name>
  </maintainer>
  <maintainer type="project">
    <email>[email protected]</email>
  </maintainer>
  <use>
    <flag name="epydoc">Build html API documentation with epydoc.</flag>
    <flag name="ipc">Use inter-process communication between Portage and running ebuilds.</flag>
    <flag name="pypy2_0">Use pypy-c2.0 as Python interpreter.</flag>
    <flag name="python2">Use python2 as Python interpreter.</flag>
    <flag name="python3">Use python3 as Python interpreter.</flag>
    <flag name="xattr">
      Preserve extended attributes (filesystem-stored metadata) when
      installing files. Usually only required for hardened systems.
    </flag>
  </use>
  <upstream>
    <bugs-to>mailto:[email protected]</bugs-to>
    <changelog>https://gitweb.gentoo.org/proj/portage.git/plain/RELEASE-NOTES</changelog>
    <doc>https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage</doc>
  </upstream>
</pkgmetadata>

Split maintainership

This example splits the maintainership based on package versions using the attribute restrict. According to the metadata.xml of sys-boot/grub, the ebuilds for version 2 and above are maintained by [email protected] whereas earlier versions are maintained by the Gentoo Base System project. Note the use of ">" as opposed to ">" in restrict.

The example also uses the <pkg> tag in USE flag descriptions. Slot dependency specifiers are not allowed inside <pkg>, therefore the notation <pkg>sys-boot/grub</pkg>:2 is adopted as opposed to <pkg>sys-boot/grub:2</pkg>.

Lastly, the <remote-id> tag in the upstream description is demonstrated.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
  <maintainer restrict="&gt;=sys-boot/grub-2" type="person">
    <email>[email protected]</email>
  </maintainer>
  <maintainer type="project">
    <email>[email protected]</email>
    <name>Gentoo Base System</name>
  </maintainer>
  <use>
    <flag name="device-mapper">
      Enable support for device-mapper from <pkg>sys-fs/lvm2</pkg>
    </flag>
    <flag name="efiemu">
      Build and install the efiemu runtimes
    </flag>
    <flag name="fonts">Build and install fonts for the gfxterm module</flag>
    <flag name="mount">
      Build and install the grub-mount utility
    </flag>
    <flag name="libzfs">
      Enable support for <pkg>sys-fs/zfs</pkg>
    </flag>
    <flag name="multislot">
      Allow concurrent installation of <pkg>sys-boot/grub</pkg>:0 and
      <pkg>sys-boot/grub</pkg>:2 by renaming all programs.
    </flag>
    <flag name="themes">Build and install GRUB themes (starfield)</flag>
    <flag name="truetype">
      Build and install grub-mkfont conversion utility
    </flag>
  </use>
  <upstream>
    <remote-id type="sourceforge">dejavu</remote-id>
  </upstream>
</pkgmetadata>

Slots and subslots

The main focus of this example is to demonstrate how slots and subslots are specified, by examining the metadata of media-libs/libpng. There may be multiple reasons for slotting depending on the nature of the package. For this particular package, it can be seen that the slots are used to provide different versions of the library with varying binary compatibility and that developers are advised to build against the slot 0. Furthermore, different versions of this package with the same subslot provide the same Application Binary Interface (ABI), according to the description specified in the <subslots> tag.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
  <maintainer type="project">
    <email>[email protected]</email>
    <name>Gentoo Base System</name>
  </maintainer>
  <use>
    <flag name="apng">support unofficial APNG (Animated PNG) spec</flag>
  </use>
  <upstream>
    <remote-id type="cpe">cpe:/a:libpng:libpng</remote-id>
    <remote-id type="sourceforge">apng</remote-id>
  </upstream>
  <slots>
    <slot name="0">
      For building against. This is the only slot
      that provides headers and command line tools.
    </slot>
    <slot name="1.2">
      For binary compatibility, provides libpng12.so.0 only.
    </slot>
    <slot name="1.5">
      For binary compatibility, provides libpng15.so.15 only.
    </slot>
    <subslots>Reflect ABI compatibility for libpng.so.</subslots>
  </slots>
</pkgmetadata>

Maintainer-needed

Maintainer-needed ("orphaned") packages have no maintainers responsible for them. Per GLEP 67, these packages must not contain any <maintainer> subtags under <pkgmetadata> in their metadata.xml. A strict test for this condition would be:

[[ $(xmllint --xpath "count(/pkgmetadata/maintainer)" metadata.xml) -eq 0 ]]

By convention, a comment line containing the string maintainer-needed is inserted. Other tags which are relevant to the package may be present in the metadata. Bugs for these packages must be assigned to [email protected]. The QA team periodically generates the orphaned packages list along with their corresponding bugs as part of the QA reports.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
  <!-- maintainer-needed -->
  <upstream>
    <maintainer status="active">
      <email>[email protected]</email>
      <name>Matt Rasmussen</name>
    </maintainer>
    <doc lang="en">http://keepnote.org/manual/</doc>
    <bugs-to>https://code.google.com/p/keepnote/issues/list</bugs-to>
  </upstream>
  <longdescription lang="en">
    KeepNote is a note taking application. With KeepNote, you can
    store your class notes, TODO lists, research notes, journal entries,
    paper outlines, etc in a simple notebook hierarchy with rich-text
    formatting, images, and more. Using full-text search, you can
    retrieve any note for later reference.
  </longdescription>
</pkgmetadata>

Category metadata

For categories, metadata.xml specifies a long description (in English and optionally in other languages). A typical example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catmetadata SYSTEM "https://www.gentoo.org/dtd/metadata.dtd">
<catmetadata>
  <longdescription lang="en">
    The app-vim category contains plugins and syntax file
    packages for the Vim text editor.
  </longdescription>
  <longdescription lang="de">
    Die Kategorie app-vim enthält Plugins und Syntax-Pakete
    für den Vim Texteditor.
  </longdescription>
</catmetadata>

When creating a new category, creating a metadata.xml file along with a <longdescription> in English is mandatory. Translations are handled by any interested developer who speaks a language sufficiently well.

The correct way to commit a category metadata.xml file is currently:

xmllint --noout --valid metadata.xml
git add metadata.xml
git commit --gpg-sign

The commit message should be formatted properly. A sample commit is shown below:

commit db359439bcd52f5a7f20d2332ab62feb16657504
Author: Alexis Ballier <[email protected]>
Date:   Tue Sep 22 10:47:49 2015 +0200

  dev-ros: Add metadata.xml for the category.

Package and category metadata.xml