Documentation> Concepts

Basis - Package management - Multimedia - Interface - Directory structure - Networking - Printing - Security - Hardware

Specification

We tried to document this format here

RPM XML Metadata

RPM XML Metadata format is mostly used for online repositories on the internet. It has its origins in the YUM package manager.

Just lately it was extended to support repositories split across multiple media.

Repository layout

Repositories are represented in XML - actually, the repository metadata is stored in gzipped XML files, in a repodata subdirectory on the server, for example:

http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/repodata/

with the following files:

repomd.xml: main repository file, very small, contains references to the others, as well as checksums and timestamps;
primary.xml.gz: contains the most important information: list of packages (with version, release, architecture), what it requires, size of the package, summary, description, etc....
filelists.xml.gz: contains the list of files that are included in the packages
other.xml.gz: not used by all package managers, it contains the changelog information of every package.

Repository Index

The repomd.xml file is the repository index. It list one or more metadata entries, using the data tag, which can be:

a primary file (package lists)
filelists (files in packages)
groups (predefined selection of packages)
patches list
other (changelogs and extra data)

Example

<?xml version="1.0" encoding="UTF-8"?>
<repomd xmlns="http://linux.duke.edu/metadata/repo">
<data type="primary">
  <location href="repodata/primary.xml.gz"/>
  <checksum type="sha">d70ba931f304a0bc1740deeaaf2a6bff62981ab7</checksum>
  <timestamp>1165253780</timestamp>
  <open-checksum type="sha">35864cccfa0553fce9e43438c70b9bb83f64bc6c</open-checksum>
  </data>
  <data type="filelists">
    <location href="repodata/filelists.xml.gz"/>
    <checksum type="sha">9f2579b7698442e4f419c82c4671be0417ce5627</checksum>
    <timestamp>1165253780</timestamp>
    <open-checksum type="sha">a97b92c82a74a7960d8ab51214983afc38003cbf</open-checksum>
  </data>

Metadata Signature and Checksum

Read the Metadata Signature model.

Based on this model, the master index is repomd.xml, and the signature has to be provided as repomd.xml.asc.

The public part of the key used to sign the master index can be provided as repomd.xml.key

External links

Read here for more information on RPM-MD

How to extend rpm-md metadata with non standard data

Create a separate xml file and a resource type, and insert it into repomd.xml index. If the type is not known, clients should ignore it.

Data to be appended to primary.xml data (packages)

The convention is to use a $foodata.xml file. Enclose the attributes in a 'package' tag referencing the package the attributes should be appended. This is right now done using pkgid attribute. However clients are free to do the matching using name, arch and ver.

rpmmd already defines some extensions over primary, like otherdata (other.xml).

<otherdata xmlns="http://linux.duke.edu/metadata/other" packages="101">
  <package pkgid="b78f8664cd90efe42e09a345e272997ef1b53c18"
           name="zaptel-kmp-default"
           arch="i586"><version epoch="0"
           ver="1.2.10_2.6.22_rc4_git6_2" rel="70"/>
    <myextendedattribute>somevalue  for it</myextendedattribute>
</otherdata>

Once this attributes become standard and supported in other clients, you may have them in primary.xml.

SUSE specific data to be appended to primary.xml data (packages)

As already explained, using the susedata tag:

<susedata>
    <package pkgid="b78f8664cd90efe42e09a345e272997ef1b53c18"
             name="zaptel-kmp-default"
             arch="i586"><version epoch="0"
             ver="1.2.10_2.6.22_rc4_git6_2" rel="70"/>
         <myextendedattribute>somevalue  for it</myextendedattribute>
</susedata>

And reference it in metadata as suse.xml (or susedata.xml).

Extra data not directly related to packages

The convention is to use $fooinfo.xml file. The format can be as you need it. One example of this extensions are updateinfo.xml (which has extra information about updates, but not appended to the package data) and deltainfo.xml which contains information related to deltarpm availability (which is information associated with the repository but not directly with each package ).

Current Extensions

For information on how to easily add extension data to a repository created using "createrepo" tool. See the enhancerepo tool.

Maintenance Patches/Fixes (updateinfo.xml)

Code 11

Maintenance updates are described using updateinfo.xml

Also see the Maintenance howto
deltainfo.xml used to support delta rpms. Format is the same as yum-presto

Code 10

Maintenance updates were described using patches.xml *(OBSOLETE)*

Non-Package items: Patterns and Products

products.xml contains metadata of included products.
patterns.xml contains metadata of included patterns.

SUSE primary data (susedata.xml), extensions to primary.xml

Code 11

susedata.xml extension is supported on Code11 and later

Any primary.xml tag is supported plus SUSE own tags.

See here for information on extending primary.xml and the format of susedata.xml.

Additional tags defined:

eula

Sets the eula attribute which is confirmed by applications before installing the item.

keywords

Adds a keyword to flag the package. Arbitrary tags, which some applications can give special meaning.

Example

<susedata>
    <package pkgid="b78f8664cd90efe42e09a345e272997ef1b53c18"
             name="zaptel-kmp-default"
             arch="i586"><version epoch="0"
             ver="1.2.10_2.6.22_rc4_git6_2" rel="70">
         <keyword>l3_supported</keyword>
         <keyword>crapware</keyword>
         <eula>I OWN you!</eula>
    </package>
</susedata>

Vendor support level for a package

Vendor support level can be explicitly added to a package by just adding a keyword to it like specified above:

The supported keywords are:

support_unsupported
support_acc
support_l1
support_l2
support_l3

The support levels descriptions are based on [The ones described here http://support.novell.com/products/linuxpointofservice/supported_packages/] and they are relative to the support offered to the vendor specified in the vendor tag of the package, and not necessarily the distributor.

SUSE repository info (suseinfo.xml), extensions to repomd.xml

Code 11

suseinfo.xml extension is supported on Code11 and later

Extension to repomd.xml repository (data not associated with a package).

<suseinfo>
  <!-- Expiration of the repository since generated timestamp, in seconds -->
  <expire>3600</expire>
  <tags>
    <content>foobar</content>
    <content>unstable</content>
    <distro cpeid="cpe://o:opensuse">openSUSE 11.0</distro>
    <updates cpeid="cpe://o:sle">SLE 11.0</updates>
    <distro cpeid="cpe://o:sle">SLE 11.0</distro>
  </tags>
</suseinfo>

The content tag specifies arbitrary keywords.
The distro tag hints that packages in this repo are meant to run in certain platform.
The updates tag hints what product does this repository provides updates for.

For example, the SLE11 SDK update repository distro tag would be SLE11, but the update tag would be SLE11 SDK.

An additional way to add keywords in suseinfo will be deprecated:

  <!-- Arbitrary tags -->
  <keywords>
    <k>update</k>
    <k>unstable</k>
  </keywords>

Use the content tag instead.

This way of adding keywords to the repo index will make its way into the standard YUM metadata ( see this thread, with exception of the updates key.

  <tags>
    <content>foobar</content>
    <content>unstable</content>
    <distro cpeid="cpe://o:opensuse">openSUSE 11.0</distro>
    <updates cpeid="cpe://o:sle">SLE 11.0</updates>
    <distro cpeid="cpe://o:sle">SLE 11.0</distro>
  </tags>

Outdated Metadata Hint

It is the "expire" tag.

Imagine Joe user has an update repo pointing to a mirror directly (no redirector). The mirror goes out of sync (however it is still reachable). He does not receive any warning, and meanwhile the main repo has lot of updates.

The server has a hint on how often the metadata is regenerated due to a change. The client could detect this and hint the user that the metadata has not been updated since long time.

The value is only a hint. The user should be able to disable or alter it.

The generated timestamp is calculated as the newer timestamp of all the data resources.

If the timestamp + expire < now, then the repo might be outdated (this is only a hint)

The expire value should be overridable in zypp.conf as a global, or per repository in the .repo file.

The user can disable the check by overriding the expire value.

Disk usage

  <diskusagedata>
    <package pkgid="..." name="3ddiag" ver="0.742" rel="45" arch="i586">
      <diskusage>
        <dirs>
          <dir name="/" size="56" count="11"/>
          <dir name="usr/" size="56" count="11"/>
          <dir name="usr/bin/" size="38" count="10"/>
          <dir name="usr/share/" size="18" count="1"/>
          <dir name="usr/share/doc/" size="18" count="1"/>
        </dirs>
      </diskusage>
    </package>
    <package pkgid="..." name="915resolution" ver="0.5.3" rel="74" arch="i586">
      <diskusage>
        <dirs>
          <dir name="/" size="27" count="7"/>
        </dirs>
      </diskusage>
    </package>
  </diskusagedata>

See here for information on extending primary.xml and the format of diskusagedata.xml.

Additional tags defined:

diskusagedata

openSUSE:Standards Rpm Metadata

Contents

Specification

RPM XML Metadata

Repository layout

Repository Index

Example

Metadata Signature and Checksum

External links

How to extend rpm-md metadata with non standard data

Data to be appended to primary.xml data (packages)

SUSE specific data to be appended to primary.xml data (packages)

Extra data not directly related to packages

Current Extensions

Maintenance Patches/Fixes (updateinfo.xml)

Non-Package items: Patterns and Products

SUSE primary data (susedata.xml), extensions to primary.xml

eula

keywords

Example

Vendor support level for a package

SUSE repository info (suseinfo.xml), extensions to repomd.xml

Outdated Metadata Hint

Disk usage