plucky (5) os-release.5.gz

Provided by: manpages-de_4.25.1-1_all bug

BEZEICHNUNG

       os-release, initrd-release, extension-release - Betriebssystemidentifikation

ÜBERSICHT

           /etc/os-release
           /usr/lib/os-release
           /etc/initrd-release
           /usr/lib/extension-release.d/extension-release.ABBILD

BESCHREIBUNG

       Die Dateien /etc/os-release und /usr/lib/os-release enthalten Betriebssystemidentifizierungsdaten.

       Das Dateiformat von os-release ist eine durch Zeilenumbrüche getrennte Liste von umgebungsartigen,
       Shell-kompatiblen Variablenzuweisungen. Es ist möglich, die Konfiguration aus Bourne-Shell-Skripten
       einzulesen, allerdings werden außer einfachen Variablenzuweisungen keine Shell-Funktionalitäten
       unterstützt. (Das bedeutet, Variablenexpansion wird explizit nicht unterstützt). Damit wird Anwendungen
       erlaubt, die Datei einzulesen, ohne eine Shell-kompatible Ausführungseinheit zu implementieren.
       Variablenzuweisungen müssen in doppelte oder einzelne englische Anführungszeichen eingeschlossen werden,
       falls sie Leerzeichen, Semikola oder andere besondere Zeichen außerhalb von A…Z, a…z, 0…9 enthalten.
       (Zuweisungen, die diese besonderen Zeichen nicht enthalten, können auch in Anführungszeichen
       eingeschlossen werden, dies ist aber optional.) Besondere Zeichen der Shell (»$«, Anführungszeichen,
       Rückwärtsschrägstrich, Gravis) müssen im Shell-Stil mit Rückwärtsschrägstrichen geschützt werden. Alle
       Zeichenketten sollten in UTF-8-Kodierung sein und nicht druckbare Zeichen sollten nicht verwandt werden.
       Die Aneinanderreihung individueller Zeichenketten in Anführungszeichen wird nicht unterstützt. Zeilen,
       die mit »#« beginnen, werden als Kommentar behandelt. Leere Zeilen sind erlaubt und werden ignoriert.

       Die Datei /etc/os-release hat vor /usr/lib/os-release Vorrang. Anwendungen sollten auf erstere prüfen und
       deren Daten exklusiv nutzen, falls sie existiert, und nur auf /usr/lib/os-release zurückfallen, falls sie
       fehlt. Anwendungen sollten die Daten aus beiden Dateien nicht kombinieren. /usr/lib/os-release ist der
       bevorzugte Ort, um Betriebssystemveröffentlichungsinformationen wie Teile des Lieferantenbaums abzulegen.
       /etc/os-release sollte ein relativer Symlink auf /usr/lib/os-release sein, um Kompatibilität für
       Anwendungen bereitzustellen, die nur nach /etc/ schauen. Ein relativer Symlink anstatt eines absoluten
       ist notwendig, damit der Link auch in einer Chroot oder Initrd-Umgebung funktioniert.

       os-release enthält Daten, die durch den Betriebssystemlieferanten definiert werden und sollte im
       Allgemeinen durch den Administrator nicht geändert werden.

       Da diese Datei nur Namen und Kennungen kodiert, sollte sie nicht lokalisiert werden.

       Die Dateien /etc/os-release und /usr/lib/os-release können Symlinks auf andere Dateien sein, aber es ist
       wichtig, dass diese Datei vom frühsten Zeitpunkt des Systemstarts an verfügbar ist, und sie muss sich
       daher auf dem Wurzeldateisystem befinden.

       os-release darf keine wiederholenden Schlüssel enthalten. Dennoch sollten Leseprogramme den hinteren
       Eintrag in der Datei wählen, falls Wiederholungen auftreten, ähnlich wie das beim Einlesen von Dateien
       durch die Shell passiert. Ein Leseprogramm darf bei wiederholenden Einträge warnen.

       Für eine längere Begründung für os-release lesen Sie bitte die Ankündigung von /etc/os-release[1].

   /etc/initrd-release
       In der Initrd[2] und Exitrd spielt /etc/initrd-release die gleiche Rolle wie os-release im Hauptsystem.
       Zusätzlich bedeutet die Existenz dieser Datei, dass das System in der Initrd/Exitrd-Phase ist.
       /etc/os-release sollte ein Symlink auf /etc/initrd-release sein (oder umgekehrt), so dass Programme, die
       nur nach /etc/os-release schauen (wie oben beschrieben), korrekt funktionieren.

       Der Rest dieses Dokuments, das von os-release berichtet, sollte so verstanden werden, dass es auch für
       initrd-release gilt.

   /usr/lib/extension-release.d/extension-release.ABBILD
       /usr/lib/extension-release.d/extension-release.ABBILD spielt die gleiche Rolle für Erweiterungsabbilder
       wie os-release für das Hauptsystem und folgt der Syntax und den Regel wie in Seite Portable Dienste[3]
       beschrieben. Der Zweck dieser Datei ist die Identifizierung der Erweiterung und der Ermöglichung für das
       Betriebssystem, zu überprüfen, dass das Erweiterungsabbild auf das zugrundeliegende Betriebssystem passt.
       Dies wird typischerweise implementiert, indem geprüft wird, dass die Option ID= übereinstimmt und
       entweder SYSEXT_LEVEL= existiert und auch übereinstimmt oder, falls das nicht vorhanden ist, dass
       VERSION_ID= existiert und übereinstimmt. Dies stellt ABI/API-Kompatibilität zwischen den Ebenen sicher
       und verhindert das Zusammenführen von inkompatiblen Abbildern in einer Überlagerung.

       Um das Erweiterungsabbild selbst zu identifizieren, können die nachfolgend definierten Felder zu der
       Datei extension-release mit einem Präfix SYSEXT_ (um es im Hinblick auf Felder eindeutig zu machen, die
       auf das Basisabbild passen) hinzugefügt werden. Z.B.SYSEXT_ID=myext, SYSEXT_VERSION_ID=1.2.3.

       In dem Dateinamen extension-release.ABBILD muss der ABBILD-Anteil genau auf den Dateinamen des
       enthaltenden Abbildes mit entfernter Endung passen. Falls es nicht möglich ist, dass ein stabiler
       Abbildname garantiert werden kann, kann diese Überprüfung gelockert werden: falls genau eine Datei in dem
       Verzeichnis vorhanden ist, deren Name auf »extension-release.*« passt und die Datei mit einem
       user.extension-release.strict xattr(7) gesetzt auf die Zeichenkette »0« markiert ist, dann wird sie
       stattdessen verwandt.

       Der Rest dieses Dokuments, der von os-release handelt, sollte so gelesen werden, das er auch auf
       extension-release angewandt werden kann.

OPTIONEN

       Die folgenden Betriebssystemidentifikationsparameter können mittels os-release gesetzt werden:

   Allgemeine Informationen zum Ermitteln des Betriebssystems
       NAME=
           Eine Zeichenkette, die das Betriebssystem identifiziert, ohne Versionskomponente und für die Anzeige
           beim Benutzer geeignet. Falls nicht gesetzt, kann die Vorgabe »NAME=Linux« verwandt werden.

           Beispiele: »NAME=Fedora«, »NAME="Debian GNU/Linux"«.

       ID=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die das Betriebssystem identifiziert, ohne irgendwelche Versionsinformationen und
           geeignet für die Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen. Falls nicht
           gesetzt, kann die Vorgabe »ID=linux« verwandt werden. Beachten Sie, dass die Zeichenkette weiterhin
           in Anführungszeichen eingeschlossen werden darf, obwohl sie keine Zeichen enthält, die für die Shell
           das Einschließen in Anführungszeichen benötigten.

           Beispiele: »ID=fedora«, »ID=debian«.

       ID_LIKE=
           Eine durch Leerzeichen getrennte Liste von Betriebssystemkennungen in der gleichen Syntax wie die
           Einstellung ID=. Sie sollte Kennungen von Betriebssystemen auflisten, die eng in Zusammenhang zu dem
           lokalen Betriebssystem im Hinblick auf Paketierung und Programmierschnittstellen sind, beispielsweise
           eine oder mehrere Betriebssystemkennungen auflisten, von denen das lokale Betriebssystem abgeleitet
           ist. Ein Betriebssystem sollte im Allgemeinen nur andere Betriebssystemkennungen auflisten, von denen
           es selbst abgeleitet ist, und nicht andere Betriebssysteme, die von ihm abgeleitet sind, obwohl
           symmetrische Beziehungen möglich sind. Bauskripte und ähnliches könnten diese Variable überprüfen,
           falls sie das lokale Betriebssystem identifizieren müssen und der Wert von ID= nicht erkannt wird.
           Betriebssysteme sollten in der Reihenfolge aufgelistet werden, wie eng das lokale Betriebssystem in
           Bezug zu den aufgeführten steht, beginnend mit dem engsten. Dieses Feld ist optional.

           Beispiele: Für ein Betriebssystem mit »ID=centos« wäre eine Zuweisung von »ID_LIKE="rhel fedora"«
           geeeignet. Für ein Betriebssystem mit »ID=ubuntu« ist eine Zuweisung »ID_LIKE=debian« geeignet.

       PRETTY_NAME=
           Ein schöner Betriebssystemname in einem Format, das zur Darstellung bei Benutzern geeignet ist. Wie
           passend kann dies auf irgendeine Art den Release-Code-Namen oder die Betriebssystemversion enthalten
           oder auch nicht. Falls nicht gesetzt, kann die Vorgabe »PRETTY_NAME=Linux« verwandt werden.

           Beispiel: »PRETTY_NAME="Fedora 17 (Beefy Miracle)"«.

       CPE_NAME=
           Ein CPE-Name für das Betriebssystem, in URI-Anbindungssyntax, gemäß der Gemeinsamen
           Plattform-Aufzählungs-Spezifikation[4], wie von NIST vorgeschlagen. Dieses Feld ist optional.

           Beispiel: »CPE_NAME="cpe:/o:fedoraproject:fedora:17"«

       VARIANT=
           Eine Zeichenkette, die eine spezielle Variante oder Edition des Betriebssystems identifiziert, die
           zur Darstellung bei Benutzern geeignet ist. Dieses Feld kann den Benutzer darüber informieren, dass
           die Konfiguration dieses Systems einer speziellen abweichenden Gruppe von Regeln oder einer
           Standardkonfigurationseinstellung unterliegt. Dieses Feld ist optional und könnte nicht auf allen
           Systemen implementiert sein.

           Beispiele: »VARIANT="Server Edition"«, "VARIANT=»Smart Refrigerator Edition"«.

           Beachten Sie: Dieses Feld dient nur Anzeigezwecken. Für programmgesteuerte Entscheidungen sollte das
           Feld VARIANT_ID benutzt werden.

           Hinzugefügt in Version 220.

       VARIANT_ID=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die eine spezielle Variante oder eine spezielle Edition des Betriebssystems
           identifiziert. Dies kann von anderen Paketen interpretiert werden, um eine abweichende
           Standardkonfiguration zu ermitteln. Dieses Feld ist optional und könnte nicht auf allen Systemen
           implementiert sein.

           Beispiele: »VARIANT_ID=server«, »VARIANT_ID=embedded«.

           Hinzugefügt in Version 220.

   Informationen über die Betriebssystemversion
       VERSION=
           Eine Zeichenkette, die die Betriebssystemversion identifiziert, ohne irgendeinen Betriebssystemnamen,
           möglicherweise einschließlich eines Code-Namens für das Release, und für die Anzeige beim Benutzer
           geeignet. Dieses Feld ist optional.

           Beispiele: »VERSION=17«, »VERSION="17 (Beefy Miracle)"«.

       VERSION_ID=
           Eine Zeichenkette in Kleinbuchstaben (größtenteils numerisch, keine Leerzeichen oder andere Zeichen
           außerhalb von 0…9, a…z, ».«, »_« und »-«), die die Betriebssystemversion identifiziert, ohne
           irgendwelche Betriebssystemnamensinformationen oder Release-Code-Namen und geeignet für die
           Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen. Dieses Feld ist optional.

           Beispiele: »VERSION_ID=17«, »VERSION_ID=11.04«.

       VERSION_CODENAME=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die den Release-Namen des Betriebssystems identifiziert, ohne irgendwelche
           Betriebssystemnamensinformationen oder Release-Versionen und geeignet für die Verarbeitung durch
           Skripte oder zur Verwendung in erstellten Dateinamen. Dieses Feld ist optional und könnte nicht auf
           allen Systemen implementiert sein.

           Beispiele: »VERSION_CODENAME=buster«, »VERSION_CODENAME=xenial«.

           Hinzugefügt in Version 231.

       BUILD_ID=
           Eine Zeichenkette, das das Systemabbild eindeutig identifiziert, das ursprünglich als
           Installationsgrundlage verwandt wurde. In den meisten Fällen werden VERSION_ID oder
           IMAGE_ID+IMAGE_VERSION aktualisiert, wenn das gesamte Systemabbild während einer Aktualisierung
           ersetzt wird. BUILD_ID kann in Distributionen verwandt werden, bei denen die Version des
           ursprünglichen Installationsabbildes wichtig ist; VERSION_ID würde sich während schrittweiser
           Systemaktualisierungen ändern, aber nicht BUILD_ID. Dieses Feld ist optional.

           Beispiele: »BUILD_ID="2013-03-20.3"«, »BUILD_ID=201303203«.

           Hinzugefügt in Version 200.

       IMAGE_ID=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die ein spezielles Abbild des Betriebssystems identifiziert. Dies ist für
           Umgebungen gedacht, in denen Betriebssystemabbilder als umfassende und konsistente
           Betriebssystemabbilder vorbereitet, gebaut, ausgeliefert und aktualisiert werden. Dieses Feld ist
           optional und könnte nicht auf allen Systemen implementiert sein, insbesondere nicht auf solchen, die
           nicht über Abbilder verwaltet werden, sondern aus einzelnen Paketen auf dem lokalen System
           zusammengesetzt und aktualisiert werden.

           Beispiele: »IMAGE_ID=vendorx-cashier-system«, »IMAGE_ID=netbook-image«.

           Hinzugefügt in Version 249.

       IMAGE_VERSION=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die die Betriebssystemversion identifiziert. Dies ist zur Verwendung mit dem oben
           beschriebenen IMAGE_ID gedacht, um verschiedene Versionen des gleichen Abbilds zu unterscheiden.

           Beispiele: »IMAGE_VERSION=33«, »IMAGE_VERSION=47.1rc1«.

           Hinzugefügt in Version 249.

       RELEASE_TYPE=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die beschreibt, welche Art von Veröffentlichung diese Version des Betriebssystems
           ist. Bekannte Werte sind:

           •   »stable« ist für normale Veröffentlichungen des Systems, geeignet für den Produktiveinsatz. Im
               Allgemeinen werden stabile Veröffentlichungen kurz nach der Veröffentlichung der nächsten
               stabilen Veröffentlichung nicht mehr unterstützt. Falls die Distribution ein Modell der rollenden
               Veröffentlichung übernommen hat, könnte das allerdings nicht der Fall sein und die
               Veröffentlichung weiterhin für den Produktiveinsatz geeignet sein. Beispiele sind Fedora 40,
               Ubuntu 23.10, OpenSUSE Tumbleweed und Arch Linux.

           •   »lts« sind für Veröffentlichungen mit längerfristiger Unterstützung, geeignet für den
               Produktiveinsatz und für eine erweiterte Zeitdauer unterstützt. Im Allgemeinen erhalten
               LTS-Veröffentlichungen Unterstützung, selbst wenn eine neue Hauptversion der Distribution
               verfügbar ist. Beispiele sind Ubuntu 24.04, Debian 12 Bookworm und RHEL 9.4.

           •   »development« ist für instabile Versionen des Systems, die für den Produktiveinsatz nicht
               geeignet sind, wie Alpha-, Beta- oder rollende instabile Veröffentlichungen. Beispiele sind
               Fedora Rawhide, Debian Testing, Fedora 40 Beta und GNOME OS Nightly.

           •   »experiment« ist für experimentelle Bauten des Systems, die zum Testen bestimmter, in Entwicklung
               befindlicher Funktionalitäten erstellt wurden. Dies ist dazu gedacht, in Kombination mit
               EXPERIMENT= verwandt zu werden.

           Falls nicht oder auf einen unbekannten Wert gesetzt, wird angenommen, dass die Veröffentlichung
           »stable« ist.

           Beispiele: "RELEASE_TYPE=development", "RELEASE_TYPE=lts".

           Hinzugefügt in Version 257.

       Um zusammenzufassen: Falls die Abbildaktualisierungen als umfassende Einheiten gebaut und ausgeliefert
       werden, passt IMAGE_ID+IMAGE_VERSION am besten. Falls andernfalls die Aktualisierungen schließlich die
       vorher installierten Inhalte komplett ersetzen, wie dies in einer typischen binären Distribution der Fall
       ist, sollte VERSION_ID verwandt werden, um die Hauptveröffentlichungen des Betriebssystems zu
       kennzeichnen. BUILD_ID kann statt oder zusätzlich zu VERSION_ID verwandt werden, wenn die Version des
       ursprünglichen Systemabbildes wichtig ist.

   Darstellungsinformationen und Links
       HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=
           Links auf Ressourcen im Internet mit Bezug zu dem Betriebssystem. HOME_URL= sollte sich auf die
           Homepage des Betriebssystems oder alternativ auf die Homepage der bestimmten Version des
           Betriebssystems beziehen. DOCUMENTATION_URL= sollte sich auf die Hauptdokumentationsseite für dieses
           Betriebssystem beziehen. SUPPORT_URL= sollte sich auf die Hauptseite für Unterstützung für das
           Betriebssystem beziehen, falls es eine solche gibt. Dies ist hauptsächlich für Anbieter, die
           Unterstützung dafür bereitstellen. BUG_REPORT_URL= sollte sich auf die Hauptseite für die
           Fehlerdatenbank für das Betriebssystem beziehen, falls es eine solche gibt. Dies ist hauptsächlich
           für Betriebssysteme gedacht, die sich auf Qualitätssicherung der Gemeinschaft verlassen.
           PRIVACY_POLICY_URL= sollte sich auf die Hauptseite der Datenschutzrichtlinie für das Betriebssystem
           beziehen, falls es eine solche gibt. Diese Einstellungen sind optional und es ist typisch, das nur
           ein Teil dieser Einstellungen bereitgestellt werden. Diese URLs sind für die Angabe in Oberflächen
           »Über dieses System« gedacht, unter Links mit den Überschriften »Über dieses Betriebssystem«, »Hilfe
           erhalten«, »Einen Fehler berichten« oder »Datenschutzrichtlinie«. Diese Werte sollten im
           RFC3986-Format[5] sein und sollten »http:«- oder »https:«-URLs und möglicherweise »mailto:« oder
           »tel:« sein. Für jede Einstellung darf nur eine URL aufgelistet werden. Falls mehrere Ressourcen
           referenziert werden müssen, wird empfohlen, eine Online-Anlaufstelle bereitzustellen, auf der alle
           verfügbaren Ressourcen verlinkt sind.

           Beispiele: »HOME_URL="https://fedoraproject.org/"«, »BUG_REPORT_URL="https://bugzilla.redhat.com/"«.

       SUPPORT_END=
           Das Datum, an dem die Unterstützung für diese Version des Betriebssystems endet. (Was genau »Ende der
           Unterstützung« bedeutet hängt vom Lieferanten ab, aber im Allgemeinen sollten Benutzer davon
           ausgehen, dass Aktualisierungen, einschließlich Sicherheitskorrekturen, nicht bereitgestellt werden.)
           Der Wert ist ein Datum im ISO-8601-Format »YYYY-MM-DD« und gibt den ersten Tag an, den dem die
           Unterstützung nicht bereitgestellt wird.

           Beispielsweise bedeutet »SUPPORT_END=2001-01-01«, dass das System bis zum letzten Tag des letzten
           Jahrtausends unterstützt wurde.

           Hinzugefügt in Version 252.

       LOGO=
           Eine Zeichenkette, die den Namen eines Icons wie er in der
           Freedesktop.org-Icon-Thema-Spezifikation[6] definiert ist, angibt. Dies kann von graphischen
           Anwendungen zur Darstellung eines Logos des Betriebssystems oder des Distributors verwandt werden.
           Dieses Feld ist optional und muss nicht notwendigerweise auf allen Systemen implementiert sein.

           Beispiele: »LOGO=fedora-logo«, »LOGO=distributor-logo-opensuse«

           Hinzugefügt in Version 240.

       ANSI_COLOR=
           Eine vorgeschlagene Farbe zur Darstellung des Betriebssystemnamens auf der Konsole. Dies sollte als
           Zeichenkette angegeben werden, die zur Einbindung in den »ESC [ m ANSI/ECMA-48«-Maskierungscode zum
           Setzen der graphischen Bildwiedergabe geeignet ist. Dieses Feld ist optional.

           Beispiele: »ANSI_COLOR="0;31"« für rot, »ANSI_COLOR="1;34"« für helles blau oder
           »ANSI_COLOR="0;38;2;60;110;180"« für Fedora-blau.

       VENDOR_NAME=
           Der Name des Betriebssystemlieferanten. Dies ist der Name der Organisation oder der Firma, die das
           Betriebssystem erstellt. Dieses Feld ist optional.

           Dieser Name ist dazu gedacht, in graphischen Oberflächen in »Über dieses System« oder in
           Software-Aktualisierungs-Oberflächen bei Bedarf offengelegt zu werden, um den
           Betriebssystemlieferanten von dem Betriebssystem selbst zu unterscheiden. Er sollte menschenlesbar
           sein.

           Beispiele: »VENDOR_NAME="Fedora Project"« für Fedora Linux, »VENDOR_NAME="Canonical"« für Ubuntu.

           Hinzugefügt in Version 254.

       VENDOR_URL=
           Die Homepage des Betriebssystemlieferanten. Dieses Feld ist optional. Das Feld VENDOR_NAME= sollte
           gesetzt sein, wenn dieses gesetzt ist, allerdings sollten Clients damit umgehen können, dass jedes
           von beiden fehlen könnte.

           Der Wert sollte im RFC3986-Format[5] und eine »http:«- oder »https:«-URL sein. Nur eine URL darf in
           dieser Einstellung aufgeführt sein.

           Beispiele: »VENDOR_URL="https://fedoraproject.org/"«, »VENDOR_URL="https://canonical.com/"«.

           Hinzugefügt in Version 254.

       EXPERIMENT=
           Eine menschenlesbare Beschreibung die darstellt, wodurch der aktuelle Betriebssystem-Bau
           experimentell ist. Dieses Feld ist optional. Das Feld RELEASE_TYPE= sollte auf »experiment« gesetzt
           sein, wenn dieses Feld gesetzt ist, andernfalls sollten Clients dieses Feld ignorieren.

           Diese Beschreibung ist dazu gedacht, zum Zeitpunkt der Systeminstallation oder in Ȇber diese
           System«-UIs angezeigt zu werden, um Benutzer zu warnen, dass sie einen experiementellen Bau des
           Betriebssystems installieren/ausführen. Falls RELEASE_TYPE »experiment« ist aber diese Feld nicht
           gesetzt ist, dann sollte die UI dennoch den Benutzer warnen, aber sie kann ihm dann nicht erklären,
           was genau im aktuellen Bau des Betriebssystems experimentell ist.

           Beispiele: »EXPERIMENT="Umsetellung auf DNF5"« für einen experimentellen Bau von Fedora Linux zum
           Testen von DNF5, »EXPERIMENT="Portierung auf Apple M3 Chip"« für experimentelle Bauten von Asahi
           Linux, portiert auf den Apple M3 SoC, »EXPERIMENT="Mutter !1441: Dynamische
           Dreifach-/Doppelt-Pufferung (v4)"« für Bauten des GNOME-Betriebssystems von Mutters CI für die
           Zusammenführungsanfrage !1441.

           Hinzugefügt in Version 257.

       EXPERIMENT_URL=
           Die Hauptinformationsseite die darstellt, wodurch der aktuelle Betriebssystem-Bau experimentell ist,
           wo Benutzer mehr über den experimentellen Status lernen und möglicherweise Rückmeldungen hinterlassen
           können. Dieses Feld ist optional. Das Feld EXPERIMENT= sollte gesetzt sein, wenn dieses gesetzt ist,
           allerdings sollten Clients damit umgehen können, dass jedes von beiden fehlen könnte.

           Der Wert sollte im RFC3986-Format[5] und eine »http:«- oder »https:«-URL sein. Nur eine URL darf in
           dieser Einstellung aufgeführt sein.

           Beispiele, die den obigen Beispielen in EXPERIMENT= entsprechen:
           »EXPERIMENT_URL="https://fedoraproject.org/wiki/Changes/SwitchToDnf5"«,
           »EXPERIMENT_URL="https://github.com/AsahiLinux/docs/wiki/M3-Series-Feature-Support"«,
           »EXPERIMENT_URL="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441"«.

           Hinzugefügt in Version 257.

   Vorgaben und Metadaten auf Distributionsebene
       DEFAULT_HOSTNAME=
           Eine Zeichenkette, die den Rechnernamen festlegt, falls hostname(5) nicht vorhanden ist und keine
           weitere Konfigurationsquelle den Rechnernamen festlegt. Muss entweder ein freistehender
           DNS-Kennzeichner sein (eine Zeichenkette, die aus 7-Bit-ASCII-Zeichen in Kleinschreibung besteht und
           keine Leerzeichen und Punkte enthält, begrenzt auf das Format, das für DNS-Domain-Namen erlaubt ist),
           oder eine Abfolge solcher Kennzeichner, getrennt durch einzelne Punkte, die einen gültigen DNS FQDN
           bildet. Der Rechnername darf höchstens 64 Zeichen lang sein, was eine Linux-Begrenzung ist (DNS
           erlaubt längere Namen).

           Siehe org.freedesktop.hostname1(5) für eine Beschreibung, wie systemd-hostnamed.service(8) den
           Rückfall-Rechnernamen bestimmt.

           Hinzugefügt in Version 248.

       ARCHITECTURE=
           Eine Zeichenekette, die die CPU-Architektur angibt, die die Programme des Anwendungsraums benötigen.
           Die Architekturkennzeichner sind identisch zu den in systemd.unit(5) beschriebenen für
           ConditionArchitecture=. Das Feld ist optional und sollte nur verwandt werden, wenn nur eine einzelne
           Architektur unterstützt wird. Sie könnte redundante Informationen bereitstellen, wenn sie in einer
           GTP-Partition mit einem GUID-Typ verwandt wird, der bereits die Architektur kodiert. Falls dies nicht
           der Fall ist, sollte die Architektur z.B. in einem Erweiterungsabbild festgelegt werden, um zu
           verhindern, dass ein inkompatibler Rechner sie lädt.

           Hinzugefügt in Version 252.

       SYSEXT_LEVEL=
           Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen außerhalb von 0…9, a…z,
           ».«, »_« und »-«), die die Unterstützungsstufe für Betriebssystemerweiterungen festlegt, um
           anzuzeigen, welche Erweiterungs-Abbilder unterstützt werden. Siehe
           /usr/lib/extension-release.d/extension-release.ABBILD, initrd[2] und systemd-sysext(8) für weitere
           Informationen.

           Beispiele: »SYSEXT_LEVEL=2«, »SYSEXT_LEVEL=15.14«.

           Hinzugefügt in Version 248.

       CONFEXT_LEVEL=
           Semantisch zu SYSEXT_LEVEL= identisch, aber für Confext-Abbilder. Siehe
           /etc/extension-release.d/extension-release.ABBILD für weitere Informationen.

           Beispiele: »CONFEXT_LEVEL=2«, »CONFEXT_LEVEL=15.14«.

           Hinzugefügt in Version 254.

       SYSEXT_SCOPE=
           Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren Zeichenketten »system«, »initrd«
           und »portable«. Dieses Feld wird nur in extension-release.d/-Dateien unterstützt und zeigt an, auf
           welche Umgebungen die Systemerweiterung anwendbar ist: d.h. reguläre Systeme, für Initrd und Exitrd
           oder für portierbare Diensteabbilder. Falls nicht festgelegt, wird »SYSEXT_SCOPE=system portable«
           impliziert, d.h. jede Systemerweiterung ohne dieses Feld ist auf reguläre Systeme und portierbare
           Diensteumgebungen anwendbar, aber nicht auf Initrd/Exitrd-Umgebungen.

           Hinzugefügt in Version 250.

       CONFEXT_SCOPE=
           Semantisch zu SYSEXT_SCOPE= identisch, aber für Confext-Abbilder.

           Hinzugefügt in Version 254.

       PORTABLE_PREFIXES=
           Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren
           Präfix-Übereinstimmungszeichenketten für die Logik der Portierbaren Dienste[3]. Dieses Feld dient
           zwei Zwecken: Es informiert, kennzeichnet portierbare Diensteabbilder als solche (und ermöglicht
           damit, dass sie von anderen Betriebssystemabbildern unterschieden werden können, wie bootbaren
           Systemabbildern). Es wird auch verwandt, wenn ein portierbares Diensteabbild angehängt wird: das
           festgelegte oder implizierte portierbare Dienstepräfx wird gegen die hier festgelegte Liste geprüft,
           um Beschränkungen, wie Abbilder an das System angehängt werden dürfen, durchzusetzen.

           Hinzugefügt in Version 250.

   Hinweise
       Falls Sie diese Datei verwenden, um das Betriebssystem oder eine bestimmte Version davon zu ermitteln,
       benutzen Sie die Felder ID und VERSION_ID, möglicherweise mit ID_LIKE als Rückfallwert. Wenn Sie nach
       einer Betriebssystemkennungszeichenkette für die Darstellung beim Benutzer suchen, verwenden Sie das Feld
       PRETTY_NAME.

       Beachten Sie, dass Betriebssystemanbieter sich entscheiden könnten, keine Versionsinformationen zu
       liefern, beispielsweise um rollende Veröffentlichungen (»rolling releases«) zu berücksichtigen. In diesen
       Fällen können VERSION und VERSION_ID ungesetzt sein. Anwendungen sollte sich nicht darauf verlassen, dass
       diese Felder gesetzt sind.

       Betriebssystemanbieter können das Dateiformat erweitern und neue Felder einführen. Es wird nachdrücklich
       empfohlen, neuen Feldern einen betriebssystemspezifischen Namen voranzustellen, um Namenskollisionen zu
       vermeiden. Anwendungen, die diese Datei lesen, müssen unbekannte Felder ignorieren.

       Beispiel: »DEBIAN_BTS="debbugs://bugs.debian.org/"«.

       Verwalter von Containern und Sandbox-Laufzeitumgebungen können die Identifizierungsdaten des Rechners
       Anwendungen zur Verfügung stellen, indem sie die Datei /etc/os-release (falls verfügbar, andernfalls
       /usr/lib/os-release als Rückfalloptione) als /run/host/os-release bereitstellen.

BEISPIELE

       Beispiel 1. Datei os-release für Fedora Workstation

           NAME=Fedora
           VERSION="32 (Workstation Edition)"
           ID=fedora
           VERSION_ID=32
           PRETTY_NAME="Fedora 32 (Workstation Edition)"
           ANSI_COLOR="0;38;2;60;110;180"
           LOGO=fedora-logo-icon
           CPE_NAME="cpe:/o:fedoraproject:fedora:32"
           HOME_URL="https://fedoraproject.org/"
           DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/"
           SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
           BUG_REPORT_URL="https://bugzilla.redhat.com/"
           REDHAT_BUGZILLA_PRODUCT="Fedora"
           REDHAT_BUGZILLA_PRODUCT_VERSION=32
           REDHAT_SUPPORT_PRODUCT="Fedora"
           REDHAT_SUPPORT_PRODUCT_VERSION=32
           PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
           VARIANT="Workstation Edition"
           VARIANT_ID=workstation

       Beispiel 2. extension-release file für eine Erweiterung für Fedora Workstation 32

           ID=fedora
           VERSION_ID=32

       Beispiel 3. os-release in sh(1) einlesen

           #!/bin/sh -eu
           # SPDX-License-Identifier: MIT-0

           test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
           . "${os_release}"

           echo "Ausführung auf ${PRETTY_NAME:-Linux}"

           if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
               echo "Sieht nach Debian aus!"
           fi

       Beispiel 4. os-release in python(1) (Version >= 3.10) einlesen

           #!/usr/bin/python
           # SPDX-License-Identifier: MIT-0

           import platform
           os_release = platform.freedesktop_os_release()

           pretty_name = os_release.get('PRETTY_NAME', 'Linux')
           print(f'Ausführung auf {pretty_name!r}')

           if 'fedora' in [os_release.get('ID', 'linux'),
                           *os_release.get('ID_LIKE', '').split()]:
               print('Sieht nach Fedora aus!')

       Siehe Dokumentation für platform.freedesktop_os_release[7] für weitere Details.

       Beispiel 5. os-release in python(1) (jede Version) einlesen

           #!/usr/bin/python
           # SPDX-License-Identifier: MIT-0

           import ast
           import re
           import sys

           def read_os_release():
               try:
                   filename = '/etc/os-release'
                   f = open(filename)
               except FileNotFoundError:
                   filename = '/usr/lib/os-release'
                   f = open(filename)

               for line_number, line in enumerate(f, start=1):
                   line = line.rstrip()
                   if not line or line.startswith('#'):
                       continue
                   m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line)
                   if m:
                       name, val = m.groups()
                       if val and val[0] in '"\'':
                           val = ast.literal_eval(val)
                       yield name, val
                   else:
                       print(f'{filename}:{line_number}: ungültige Zeile  {line!r}',
                             file=sys.stderr)

           os_release = dict(read_os_release())

           pretty_name = os_release.get('PRETTY_NAME', 'Linux')
           print(f'Ausführung auf {pretty_name!r}')

           if 'debian' in [os_release.get('ID', 'linux'),
                           *os_release.get('ID_LIKE', '').split()]:
               print('Sieht nach Debian aus!')

       Beachten Sie, dass die obige Version, die die eingebaute Implementierung verwendet, in den meisten Fällen
       bevorzugt wird, und dass die hier bereitgestellte offen kodierte Version als Referenz dient.

SIEHE AUCH

       systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5)

ANMERKUNGEN

        1. Ankündigung von /etc/os-release
           https://0pointer.de/blog/projects/os-release

        2. initrd
           https://docs.kernel.org/admin-guide/initrd.html

        3. Portable Dienste
           https://systemd.io/PORTABLE_SERVICES

        4. Gemeinsame Plattform-Aufzählungs-Spezifikation
           http://scap.nist.gov/specifications/cpe/

        5. RFC-3986-Format
           https://tools.ietf.org/html/rfc3986

        6. freedesktop.org-Icon-Thema-Spezifikation
           https://standards.freedesktop.org/icon-theme-spec/latest

        7.

                 platform.freedesktop_os_release
           https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.