Standards/Rpm Metadata

Specificatie

We hebben geprobeerd om dit formaat hier te documenteren

rpm XML Metadata

rpm XML Metadata formaat wordt meestal gebruikt voor online installatiebronnen op het internet. Het vond zijn oorsprong in de YUM pakketbeheerder.

Het is pas de laatste tijd dat het werd uitgebreid om installatiebronnen opgesplitst in meerdere media te ondersteunen.

Installatiebron layout

Installatiebronnen worden voorgesteld in XML - Feitelijk wordt de installatiebron metadata opgeslagen in gzipped XML bestanden, in een repodata submap op de server, bijvoorbeeld:

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

met de volgende bestanden:

repomd.xml

hoofd installatiebron bestand, zeer klein, bevat referenties naar de anderen, alsook controlesommen en tijdstempels;

primary.xml.gz

bevat de meest belangrijke informatie: lijst van pakketten (met versie, uitgave, architectuur), wat het vereist, grootte van het pakket, samenvatting, beschrijving, enz....

filelists.xml.gz

bevat de lijst met bestanden die in de pakketten inbegrepen zijn.

other.xml.gz

niet gebruikt door alle pakketbeheerders, het bevat de changelog informatie van elk pakket.

Installatiebron Index

Het repomd bestand is de installatiebron index. Het catalogiseert één of meer metadata-items, met behulp van de data-tag, die kan zijn:

• een hoofdbestand (pakkettenlijst)
• bestandenlijst (bestanden in pakketten)
• groepen (vooral gedefinieerde selectie van pakketten)
• lijst met patches
• andere (changelogs en extra data)

Metadata handtekening en Controlesom

Lees het Metadata handtekening model.

Gebaseerd op dit model, is de hoofdindex repomd.xml, en de handtekening wordt verschaft als repomd.xml.asc.

Het openbare deel van de sleutel gebruikt voor het ondertekenen van de master-index kan worden verstrekt als repomd.xml.key

Externe links

Lees hier voor verdere informatie over RPM-MD

Hoe rpm-md metadata uit te breiden met niet-standaard data

Creëer een afzonderlijk xml bastand en een brontype, en voeg het toe aan de repomd.xml index. als het type niet gekend is, zouden clients het moeten negeren.

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/Novell 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 (Code11)

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

Patches (updateinfo.xml)

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

Non-Package primary files (product.xml patterns.xml), extensions to primary.xml

TODO Document:

• Patterns
• Products

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

Use file susedata.xml.

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.

keyword

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

Examples

<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>
</susedata>

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

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 distribution tag hints that packages in this repo are meant to run in certain platform.
• The distribution 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

Afgekeurde Extensies (Code11)

Patches (patches.xml)

TODO

Benodigde Extensies

Proposed Extensions

Vertalingen in afzonderlijke bestanden