Standards/YaST2 Repository Metadata/content

aus openSUSE, der freien Wissensdatenbank

Rationale

Was ist ein Produkt und was macht ein Produkt zu einem Produkt?

Die Installation von bspw. openSUSE 10.2 kann auf verschiedene Arten geschehen. Am Ende ist aber immer openSUSE 10.2 auf dem Computer installiert.

Meistens.

Abhängig vom Installationsmedium variiert der Satz an installierten Paketen. Es können mehr oder weniger Übersetzungen, Spiele oder was auch immer installiert sein, allein die Kernfunktionen sind immer die gleichen, wobei es auch dabei feine Unterschiede geben kann.

Wir wollen diese Unterschiede aus Gründen der Fehlerbehung und Statistik feststellen.
Wie sonst sollten wir wissen, wie wir unsere Anstrengungen konzentrieren sollen? Mehr CDs oder bessere FTP-Depots?

Code11

Produktmetadaten

Die content-Datei im Wurzelverzeichnis des Depots definiert das Produkt. Darin hat das Produkt einen Namen, eine Version, eine Ausgabe und eine Architektur; zusätzlich hat es auch noch Abhängigkeiten. Kurz gesagt ist ein Produkt aufschlüsselbar wie ein RPM-Paket.

Beispiel

CONTENTSTYLE 11
NAME         SUSE_SLES
VERSION      11
RELEASE      0
DISTRIBUTION SUSE Linux Enterprise Server 11.0 (i686)
FLAVOR       DVD
DESCRDIR     suse/setup/descr
DATADIR      suse
LABEL        SUSE Linux Enterprise Server 11
VENDOR       SuSE Linux Products GmbH
BASEARCHS    i386
RELNOTESURL http://www.novell.com/linux/releasenotes/i386/SUSE-SLES/11/release-notes-sles.rpm
META SHA1 5f4dfc16a5395614af94392382d61e7f4d251c6e  Basis-Devel-10-235.2.i586.pat.gz
META SHA1 ff619b5e2a559c3443dfd07a3319112fa97f9af2  Dom0-10-235.2.i586.pat.gz
...
HASH SHA1 12171caa5bf085ad295c64eb01faaec7b698569f  control.xml
HASH SHA1 2f4eaf960048b9dccc6f47584c0ce31f43332ef1  media.1/info.txt
...
KEY SHA1  17162a96933229a9771ee10c0976bdc047a2f53d  gpg-pubkey-0dfb3188-41ed929b.asc
KEY SHA1  f6accbb18d705bfc104c893cf7dfca1247a33f3c  gpg-pubkey-307e3d54-481f30aa.asc

Dokumentation aktueller Tags

CONTENTSTYLE

• Muss das erste Tag der Datei content sein.
• Muss für Code11 den Wert '11' haben, bswp. CONTENTSTYLE 11

NAME wird noch hinzugefügt

• Dies wird nur intern genutzt.
• Es gelten die gleichen Einschränkungen wie bei Paketnamen.
  • Siehe dazu Name Tag bei den SUSE-Paketkonventionen

VERSION und RELEASE

• In der Form Version-Release
• Es gelten die gleichen Einschränkungen wie bei Paketversionen.

• Muss vergleichbar sein (wie auch die Version-Release-Zeichenketten bei RPMs).
• Die Version stellt die sichtbare Nummer dar, das Release ist intern, beginnt bei 0 für den GA und wird bei weiteren Neubauten erhöht.

Beispiele

VERSION 10.2
RELEASE 0 (GA Version)

VERSION 10.2
RELEASE 1 (Neu gemasterte Version)

Die Factory-Version

Für die Factory Distribution muss sich die Versionsnummer von veröffentlichten Produkten unterscheiden. Die gleiche Version in Factory zu haben ist für einen kurzen Zeitraum vertretbar, in dem Factory das zu veröffentlichende Produkt ist - was es aber für gewöhnlich nicht ist.

Sobald also bspw. openSUSE-10.2 abgetrennt wird und neue/aktualisierte Pakte in Factory eingepflegt werden, muss die Versionsnummer erhöht werden.

Die Factory-Version muss dann höher als 10.2 sein (die Entwicklung schreitet ja voran), aber niedriger als 10.3 ausfallen (so weit sind wir noch nicht).
Außerdem sollten Veränderungen im Factory-Zweig irgendwie erkennbar sein.

Bei Factory wird es also zu
VERSION 10.2.1
RELEASE 1
wobei die Release-Zahl (beginnend mit 1) jedes Mal erhöht wird, wenn der Factory-Zweig für die Veröffentlichung synchronisiert wird.

BASEARCHS

• Durch Leerzeichen unterteilte Liste von Produktarchitekturen. Pro Architektur wird dann in der Liste der verfügbaren Produkte eine Produkt erstellt.
• Matches the available product-release packages architectures.

DISTRIBUTION

Eine Zeichenkette die die Distribution bezeichnet. Die gleiche Zeichenkette wird höchstwahrscheinlich in den RPM-Dateien genutzt um die Distribution zu bezeichnen. Normalerweise eine Zusammenstellung aus Name, Version und Geschmacksrichtung (flavor).

FLAVOR

• Beschreibt den Geschmack oder die Variante eines Produkts.
• Wird für Statistiken genutzt.
• Bspw. DVD, FTP, Live, ...
• Nutzen Sie die Geschmacksrichtung nicht im Produktnamen.

PATTERNS=

• Liste von Schemata die vom Produkt vorausgewählt sind.
• Wird von YaST verarbeitet und ausgewertet.

DESCRDIR

• Wo sich die Paketliste und die Schemata befinden.

DATADIR

• Wo sich die Pakete befinden.

LABEL

• Produktname für Anzeigezwecke.
• Zusätzlich können Übersetzungen als LABEL.locale angegeben werden, bspw. LABEL.de oder LABEL.cz

META SHA1

• Definiert die Prüfsumme einer Ressource in DESCRDIR.

HASH SHA1

• Definiert die Prüfsumme einer Unabhängigen Datei, relativ zur Wurzel des Mediums.

KEY SHA1

• Definiert die Prüfsumme eine GPG-Schlüssels.

VENDOR

• Definiert den Hersteller des Produkts.
• Es muss den gleichen Wert wie das Tag <vendor> in der .prod-Datei haben.
  • Wenn die Paketdepotmetadaten für ein Paket keine Herstellerinformationen anbieten (=Vnd: in der Paketdatei), wird für den Pakethersteller dieser Wert als Rückfalloption genutzt.

UPDATEURLS

• Standardpaketdepot für Aktualisierungen.

EXTRAURLS

•  ?

OPTIONALURLS

•  ?

RELNOTESURL

• URL für die Veröffentlichungshinweise.

LINGUAS

• Liste der für dieses Produkt unterstützten Sprachen.
• Wenn Sie eine andere Sprache haben wollen, müssen Sie bspw. ein Sprach-Add-on installieren (YaST zeigt eine Warnung an, wenn eine Sprache für die Installation ausgewählt wurde, die nicht in dieser Liste ist).

LANGUAGE

• LANGUAGE wird von YaST verarbeitet und definiert die Standardsprache (wenn keine andere ausgewählt wurde).
  • linuxrc setzt beim Booten der DVD die Standardsprache.
  • Wenn ein Zusatzprodukt installiert wird, wird stattdessen die Sprache des Basisprodukts genutzt.

Veraltete Tags

• PRODUCT wird ignoriert (ersetzt durch NAME)
• DISTPRODUCT wird ignoriert (ersetzt durch DISTRIBUTION)
• DISTVERSION wird ignoriert (ersetzt durch DISTRIBUTION)
• TYPE wird ignoriert (siehe Identifizieren des Basisprodukts)
• ARCH.* wird ignoriert (ersetzt durch BASEARCHS)
• DEFAULTBASE wird ignoriert (ersetzt durch BASEARCHS)
• PROVIDES wird ignoriert
• REQUIRES wird ignoriert
• OBSOLETES wird ignoriert
  • Die Datei 'content' beschreibt ein Produkt, das innerhalb von SAT Solver/Libzypp als eine Auflösbare dargestellt wird.
  • Solch ein Produkt hat keine Abhängigkeiten, da alle Abhängigkeiten auf Paketebene ausgedrückt werden.
  • Ein Produkt hat ein passendes -release-Paket, das -release-Paket benötigt die für das Produkt unumgänglichen Pakete.
  • Es gibt keinen Ersatz für das alte REQUIRES Tag. Installationswerkzeuge können sich PATTERNS anschauen um zu wissen, welche Schemata installiert werden müssen.
• SHORTLABEL wird ignoriert
  • wird aktuell bspw. vom Bootloader genutzt, weißt aber standardmäßig auf LABEL wenn es nicht vorhanden ist
• YOUURL wird ignoriert

Nicht dokumentiert/unklar

• Welche Tags sind unumgänglich und welche sind Optional?

Für libzypp NAME, VERSION, BASEARCHS, VENDOR. Die anderen Werte werden einfach an die Anwendung weitergeleitet. Allerdings können anderen Komponenten auch andere Tags benötigen.

• Verschiedene Tags (bspw. NAME) enthalten den Hinweis "Es gelten die gleichen Einschränkungen wie bei Paketnamen". Was sind die Einschränkungen?

Siehe dazu Name Tag bei den SUSE-Paketkonventionen, aber andere Anwendung kümmern sich wahrscheinlich nicht darum...

Code10

Der Produktname

PRODUCT

ist der detaillierte Name des Produkts der exakt seine Eigenschaften beschreibt

• Keine Leerzeichen (Alle Leerzeichen werden in Unterstriche umgewandelt)
• Keine Version (dafür gib es VERSION)
• Keine Architektur
• Die gleichen Regeln die auch für die Namen von RPM-Paketen gelten

Beispiele

PRODUCT openSUSE

Die Produktversion

VERSION

spezifiziert Version-Ausgabe

• Muss vergleichbar sein (wie Versionsangaben bei RPMs)
• Die Version enthält die sichtbare Nummer, die Ausgabe ist intern und beginnt mit 0 für GA und wird bei jedem Neubau erhöht.

Beispiele

VERSION 10.2-0 (GA-Version)
VERSION 10.2-1 (Neu aufgelegte Version)

Die Factory-Version

Für die Factory Distribution muss sich die Versionsnummer von veröffentlichten Produkten unterscheiden. Die gleiche Version in Factory zu haben ist für einen kurzen Zeitraum vertretbar, in dem Factory das zu veröffentlichende Produkt ist - was es aber für gewöhnlich nicht ist.

Sobald also bspw. openSUSE-10.2 abgetrennt wird und neue/aktualisierte Pakte in Factory eingepflegt werden, muss die Versionsnummer erhöht werden.

Die Factory-Version muss dann höher als 10.2 sein (die Entwicklung schreitet ja voran), aber niedriger als 10.3 ausfallen (so weit sind wir noch nicht).
Außerdem sollten Veränderungen im Factory-Zweig irgendwie erkennbar sein.

Deshalb wird Factory VERSION 10.2.1-1, wobei die Nummer der Ausgabe (beginnend mit 1) jedes mal ansteigt, wenn der Factory-Zweig zur Öffentlichkeit synchronisiert wird.

Abhängigkeiten

Bietet/Provides

Für das verwendete Beispiels - openSUSE-10.2 auf verschiedene Arten installiert - ist das resultierende System openSUSE-10.2. Diese Tatsache muss irgendwie feststellbar sein, und dass kann über Abhängigkeiten erreicht werden.

PROVIDES

Markiert zusätzlich was das Produkt bereitstellt (neben seinem eigenen Namen)

Beispiel

PROVIDES product:openSUSE = 10.2

Es muss ausdrücklich ein product:-Vorspann vorhanden sein, da die Abhängigkeiten den Paketnamensraum vorgeben!

Veraltet/Obsoletes

Da ein neues Produkt eine Ersatz für ältere Produkte ist, sollte das durch eine passende obsoletes-Abhängigkeit ausgedrückt werden.

Beispiel

OBSOLETES product:SUSE_LINUX product:openSUSE < 10.2

openSUSE-10.2 ersetzt alle Versionen von SUSE_LINUX (egal welche Version!) und alle älteren Versionen von openSUSE.

Siehe auch

Diese Seite behandelt nicht die ganze content-Datei. Lesen Sie dazu die Beschreibung einiger anderer Teile der content-Datei (die aber auch nicht komplett ist...).