Standards/RPM Metadata

aus openSUSE, der freien Wissensdatenbank

Spezifikation

rpm XML Metadaten

Das rpm-XML-Metadatenformat wird meistens für Depots im Internet oder Netzwerk verwendet. Es hat seine Ursprünge im Paketverwalter Yellowdog Updater, Modified.

Es wurde kürzlich erweitert um Paketdepots zu unterstützen die auf mehrere Medien verteilt sind.

Depotgrundriss

Depots werden in XML dargestellt - zur Zeit werden die Depotmetadaten in mit gzip komprimierten Dateien gespeichert, welche sich in einem Unterverzeichnis namens repodata befinden, zum Beispiel:

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

Mit den folgenden Dateien:

repomd.xml

Hauptdepotdatei, sehr klein, enthält Referenzen zu anderen Dateien, darüberhinaus noch Prüfsummen und Zeitstempel.

primary.xml.gz

Enthält die wichtigsten Informationen: Liste der Pakete (mit Version, Ausgabe, Architektur), was sie voraussetzen, Größen der Pakete, Zusammenfassungen, Beschreibungen, usw....

filelists.xml.gz

Enthält eine Liste der Dateien die in den Paketen enthalten sind.

other.xml.gz

Wird nicht von allen Paketverwaltern verwendet, sie enthält das Änderungsprotokoll von jedem Paket.

Depotindex

Die repomd-Datei ist der Depotindex. Sie listet einen oder mehrere Metadateneinträge auf, indem sie das data tag benutzt, welches folgendes sein kann:

• eine primäre Datei (Paketlisten)
• Dateilisten (Dateien in Paketen)
• Gruppen (vordefinierte Selektionen von Pakten)
• Patches-Liste
• anderes (Änderungsprotokoll und Extradaten)

Metadatensignaturen und -prüfsummen

Schauen Sie sich das Metadatensiganturmodell an.

Basierend auf diesem Modell ist repomd.xml der Hauptindex und die Signatur muss als repomd.xml.asc bereitgestellt werden.

Der öffentliche Teil des zur Signierung verwendeten Schlüssels kann als repomd.xml.key bereitgestellt werden.

WWW-Verweise

Lesen Sie hier mehr Informationen zu RPM-MD

Wie man RPM-MD Metadaten mit Nicht-Standarddaten erweitert

Erstellen Sie eine separate XML-Datei und einen Ressourcentyp, die Sie dem repomd.xml-Index hinzufügen. Falls der Typ nicht pekannt ist, sollten Clients ihn ignorieren.

Daten an primary.xml-Daten (Pakete) anhängen

Für gewöhnlich wird dafür eine $foodata.xml-Datei genutzt. Schließen Sie die Attribute in ein 'package' Tag ein, das auf das Paket verweist, dem Sie die Attribute anhängen wollen. Dies wird zur Zeit über das pkgid-Attribut gelöst. Allerdings sind die Clients in ihrer Entscheidung frei, dass passende Paket auch über name, arch und ver zu finden.

RPM-MD definiert bereits einige Erweiterungen zu primaryy, wie 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>einige Werte dafür</myextendedattribute>
</otherdata>

Sobald diese Attribute zum Standard und von anderen Clients unterstützt werden, könnten Sie in primary.xml umziehen.

SUSE/Novell-spezifische Daten an primary.xml-Daten (Pakete) anhängen

Wie schon erklärt, nutzen Sie dafür das 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>einige Werte dafür</myextendedattribute>
</susedata>

Und referenzieren Sie es in den Metadaten als suse.xml (oder susedata.xml).

Zusatzdaten die nicht direkt mit Paketen zusammenhängen

Für gewöhnlich wird dafür eine $fooinfo.xml-Datei genutzt. Das Format können Sie selber festlegen. Einige Beispiele für diese Erweiterung sind updateinfo.xml (welches Zusatzinfomationen über Aktualisierungen enthält, aber nicht den Paketdaten angehängt wird) und deltainfo.xml, das Informationen zur Verfügbarkeit von deltarpm enthält (was Informationen sind, die mit dem Paketdepot zusammenhängen, aber nicht direkt mit jedem Paket).

Aktuelle Erweiterungen (Code11)

Informationen zum einfachen Hinzufügen von Zusatzdaten zu einem Paketdepot, das mit dem Werkzeug "createrepo" erstellt wurde, finden Sie im Artikel zum Werkzeug Enhancerepo.

Patches (updateinfo.xml)

• updateinfol.xml wird genutzt, um Patches zu unterstützen.
  • Werfen Sie auch einen Blick auf die Wartungsanleitung
• deltainfo.xml wird genutzt um Delta-RPMs zu unterstützen. Das Format ist das selbe wie bei yum-presto

Nicht-Pakete Primärdateien (product.xml patterns.xml), Erweiterungen zu primary.xml

Dokumentation muss noch erstellt werden:

• Schemata
• Produkte

SUSE Primärdaten (susedata.xml), Erweiterungen zu primary.xml

Nutzen die Datei susedata.xml.

Es wird jedes Tag aus primary.xml unterstütz, dazu die SUSE-eigenen Tags.

Hier finden Sie Informationen zum Erweitern von primary.xml und dem Format von susedata.xml.

Zusätzlich sind die folgenden Tags definiert:

eula

Setzt das eula-Attribut, welches von Anwendungen erst bestätigt werden muss, bevor das Objekt installiert wird.

keyword

Fügt ein Schlüsselwort hinzu, um das Paket zu kennzeichnen. Willkürliche Tags, die einigen Anwendungen bestimmte Bedeutung geben können.

Beispiele

<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-Paketdepotinfo (suseinfo.xml), Erweiterungen zu repomd.xml

Erweiterung zum repomd.xml-Depot (Daten die nicht zu Paketen gehören).

<suseinfo>
  <!-- Verfall des Paketdepots nach dem generierten Zeitstempel, in Sekunden -->
  <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>

• Das Tag content spezifiziert willkürliche Schlüsselwörter.
• Das Tag Distribution weist darauf hin, dass Pakete in diesem Paketdepot für eine bestimmte Plattform gedacht sind.
• Das Tag updates weist darauf hin, für welches Produkt dieses Paketdepot Aktualisierungen bereithält.

Beim Aktualisierungspaketdepot für SLE11 SDK wäre das Tag distro bspw. SLE11, dass Tag update wäre aber SLE11 SDK.

Ein zusätzlicher Weg, suseinfo Schlüsslwörter hinzuzufügen wird bald auslaufen:

  <!-- willkürliche Tags -->
  <keywords>
    <k>update</k>
    <k>unstable</k>
  </keywords>

Nutzen Sie stattdessen das Tag content.

Dieser Weg, dem Depotindex Schlüsselwörter hinzuzufügen wird, mit Ausnahme des Schlüssels update, seinen Weg in die Standard-YUM-Metadaten finden (lesen Sie dazu diesen Diskussionsstrang).

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

Hinweis zu veralteten Metadaten

Es handelt sich um das Text "expire".

Stellen Sie sich vor, Benutzer Johann hat ein Aktualisierungsdepot, das direkt auf einen Spiegelserver verweist (ohne Weiterleitung). Der Spiegelserver ist auf einmal nicht mehr synchron (ist aber trotzdem noch erreichbar). Er erhält keine Warnung, während das Hauptdepot in der Zwischenzeit viele Aktualisierungen hat.

Der Server hat einen Hinweis, wie oft die Metadaten auf Grund von Änderungen neu generiert wurden. Der Client kann dies feststellen und den Nutzer davor warnen, dass die Metadaten seit langer Zeit nicht mehr aktualisiert wurden.

• Der Wert ist nur ein Hinweis. Der Nutzer sollte in der Lage sein, ihn zu deaktivieren oder zu ändern.

Der generierte Zeitstempel wird als neuer Zeitstempel aller Datenressourcen kalkuliert.

Wenn Zeitstempel + Ablaufzeit < Jetzt sind, dann könnte das Depot veraltet sein (was aber nur ein Hinweis wäre).

Der Wert für expire sollte in zypp.conf global, oder in den .repo-Dateien für jedes Depot, überschreibbar sein.

Festplattennutzung

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

Hier finden Sie Informationen zum Erweitern von primary.xml und dem Format von diskusagedata.xml.

Zusätzlich definierte Tags:

• diskusagedata

Veraltete Erweiterungen (Code11)

Patches (patches.xml)

Noch zu schreiben....

Benötigte Erweiterungen

Vorgeschlagene Erweiterungen

Übersetzungen in separaten Dateien