X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fos-release.xml;h=b4cbeba39558f6f6ca86776a85ff8e061a87a600;hp=759c04d320456ddfc5887d0bdbb6c3ae62069bd6;hb=de59d29e8abc32ff8e5de6a36ddf9d04d63ccb47;hpb=01c3a63e179ae7abb7447570a82087289d1bcab4
diff --git a/man/os-release.xml b/man/os-release.xml
index 759c04d32..b4cbeba39 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -9,16 +9,16 @@
Copyright 2010 Lennart Poettering
systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
(at your option) any later version.
systemd is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
+ Lesser General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see .
-->
@@ -49,39 +49,81 @@
/etc/os-release
+ /usr/lib/os-release
Description
- The /etc/os-release file
- contains operating system identification data.
+ The /etc/os-release and
+ /usr/lib/os-release files contain
+ operating system identification data.
The basic file format of
- os-release is a
- newline-separated list of environment-like
- shell-compatible variable assignments. It is possible
- to source the configuration from shell scripts,
- however, beyond mere variable assignments no shell
- features are supported, allowing applications to read
- the file without implementing a shell compatible
- execution engine.
-
- /etc/os-release contains
- data that is defined by the operating system vendor
- and should not be changed by the administrator.
-
- Depending on the operating system other
- configuration files might be checked for OS
- identification as well, however only as
- fallback.
+ os-release is a newline-separated
+ list of environment-like shell-compatible variable
+ assignments. It is possible to source the
+ configuration from shell scripts, however, beyond mere
+ variable assignments, no shell features are supported
+ (this means variable expansion is explicitly not
+ supported), allowing applications to read the file
+ without implementing a shell compatible execution
+ engine. Variable assignment values must be enclosed in
+ double or single quotes if they include spaces,
+ semicolons or other special characters outside of A-Z,
+ a-z, 0-9. Shell special characters ("$", quotes,
+ backslash, backtick) must be escaped with backslashes,
+ following shell style. All strings should be in UTF-8
+ format, and non-printable characters should not be used.
+ It is not supported to concatenate multiple individually
+ quoted strings. Lines beginning with "#" shall be
+ ignored as comments.
+
+ The file /etc/os-release
+ takes precedence over
+ /usr/lib/os-release. Applications
+ should check for the former, and exclusively use its
+ data if it exists, and only fall back to
+ /usr/lib/os-release if it is
+ missing. Applications should not read data from both
+ files at the same
+ time. /usr/lib/os-release is the
+ recommended place to store OS release information as
+ part of vendor trees.
+ /etc/os-release should be a
+ relative symlink to
+ /usr/lib/os-release,
+ to provide compatibility with applications only
+ looking at /etc. A relative
+ symlink instead of an absolute symlink is
+ necessary to avoid breaking the link in a chroot or
+ initrd environment such as dracut.
+
+ os-release contains data
+ that is defined by the operating system vendor and
+ should generally not be changed by the
+ administrator.
+
+ As this file only encodes names and identifiers
+ it should not be localized.
+
+ The /etc/os-release and
+ /usr/lib/os-release files might
+ be symlinks to other files, but it is important that
+ the file is available from earliest boot on, and hence
+ must be located on the root file system.
+
+ For a longer rationale for
+ os-release please refer to
+ the Announcement of /etc/os-release.
Options
The following OS identifications parameters may be set using
- /etc/os-release:
+ os-release:
@@ -90,10 +132,10 @@
A string identifying
the operating system, without a
- version string, and not necessarily
- suitable for presentation to the
- user. If not set defaults to
- Linux. Example:
+ version component, and suitable for
+ presentation to the user. If not set,
+ defaults to
+ NAME=Linux. Example:
NAME=Fedora or
NAME="Debian
GNU/Linux".
@@ -104,35 +146,86 @@
A string identifying
the operating system version,
- excluding any name information and
- suitable for presentation to the
- user. Example:
- VERSION=15 or
- VERSION="15
- (Rawhide)".
+ excluding any OS name information,
+ possibly including a release code
+ name, and suitable for presentation to
+ the user. This field is
+ optional. Example:
+ VERSION=17 or
+ VERSION="17 (Beefy
+ Miracle)".
ID=
A lower-case string
+ (no spaces or other characters outside
+ of 0-9, a-z, ".", "_" and "-")
identifying the operating system,
excluding any version information and
- suitable for processing by scripts. If
- not set defaults to
- linux. Example:
- ID=fedora.
+ suitable for processing by scripts or
+ usage in generated filenames. If not
+ set, defaults to
+ ID=linux. Example:
+ ID=fedora or
+ ID=debian.
+
+
+
+ ID_LIKE=
+
+ A space-separated list
+ of operating system identifiers in the
+ same syntax as the
+ ID= setting. It should
+ list identifiers of operating systems
+ that are closely related to the local
+ operating system in regards to
+ packaging and programming interfaces,
+ for example listing one or more
+ OS identifiers the local
+ OS is a derivative from. An
+ OS should generally only list other OS
+ identifiers it itself is a derivative
+ of, and not any OSes that
+ are derived from it, though symmetric
+ relationships are possible. Build
+ scripts and similar should check this
+ variable if they need to identify the
+ local operating system and the value
+ of ID= is not
+ recognized. Operating systems should
+ be listed in order of how closely the
+ local operating system relates to the
+ listed ones, starting with the
+ closest. This field is
+ optional. Example: for an operating
+ system with
+ ID=centos, an
+ assignment of ID_LIKE="rhel
+ fedora" would be
+ appropriate. For an operating system
+ with ID=ubuntu, an
+ assignment of
+ ID_LIKE=debian is
+ appropriate.
VERSION_ID=
A lower-case string
- (mostly numeric) identifying the
- operating system version, excluding
- any name information and suitable for
- processing by scripts. Example:
- VERSION_ID=15.
+ (mostly numeric, no spaces or other
+ characters outside of 0-9, a-z, ".",
+ "_" and "-") identifying the operating
+ system version, excluding any OS name
+ information or release code name, and
+ suitable for processing by scripts or
+ usage in generated filenames. This
+ field is optional. Example:
+ VERSION_ID=17 or
+ VERSION_ID=11.04.
@@ -141,11 +234,12 @@
A pretty operating
system name in a format suitable for
presentation to the user. May or may
- not contain an OS version of some
- kind, as suitable. If not set defaults
- to Linux. Example:
- PRETTY_NAME=Fedora 15
- (Rawhide).
+ not contain a release code name or OS
+ version of some kind, as suitable. If
+ not set, defaults to
+ PRETTY_NAME="Linux". Example:
+ PRETTY_NAME="Fedora 17 (Beefy
+ Miracle)".
@@ -153,47 +247,148 @@
A suggested
presentation color when showing the
- distribution name on the console. This
+ OS name on the console. This
should be specified as string suitable
for inclusion in the ESC [ m
ANSI/ECMA-48 escape code for setting
- graphical rendition. Example:
- ANSI_COLOR=0;31 for
- red, or
- ANSI_COLOR=1;34 for
- light blue.
+ graphical rendition. This field is
+ optional. Example:
+ ANSI_COLOR="0;31"
+ for red, or
+ ANSI_COLOR="1;34"
+ for light blue.
+
+
+
+ CPE_NAME=
+
+ A CPE name for the
+ operating system, following the Common
+ Platform Enumeration
+ Specification as proposed by
+ the MITRE Corporation. This field
+ is optional. Example:
+ CPE_NAME="cpe:/o:fedoraproject:fedora:17"
+
+
+
+
+ HOME_URL=
+ SUPPORT_URL=
+ BUG_REPORT_URL=
+
+ Links to resources on
+ the Internet related the operating
+ system. HOME_URL=
+ should refer to the homepage of the
+ operating system, or alternatively
+ some homepage of the specific version
+ of the operating
+ system. SUPPORT_URL=
+ should refer to the main support page
+ for the operating system, if there is
+ any. This is primarily intended for
+ operating systems which vendors
+ provide support
+ for. BUG_REPORT_URL=
+ should refer to the main bug reporting
+ page for the operating system, if
+ there is any. This is primarily
+ intended for operating systems that
+ rely on community QA. These settings
+ are optional, and providing only some
+ of these settings is common. These
+ URLs are intended to be exposed in
+ "About this system" UIs behind links
+ with captions such as "About this
+ Operating System", "Obtain Support",
+ and "Report a Bug". The values should
+ be in RFC3986
+ format, and should be
+ http: or
+ https: URLs, and
+ possibly mailto: or
+ tel:. Only one URL
+ shall be listed in each setting. If
+ multiple resources need to be
+ referenced, it is recommended to
+ provide an online landing page linking
+ all available resources. Examples:
+ HOME_URL="https://fedoraproject.org/"
+ and
+ BUG_REPORT_URL="https://bugzilla.redhat.com/"
+
+
+ BUILD_ID=
+
+ A string uniquely
+ identifying the system image used as
+ the origin for a distribution (it is
+ not updated with system updates). The
+ field can be identical between
+ different VERSION_IDs as BUILD_ID is
+ an only a unique identifier to a
+ specific version. Distributions that
+ release each update as a new version
+ would only need to use VERSION_ID as
+ each build is already distinct based
+ on the VERSION_ID. This field is
+ optional. Example:
+ BUILD_ID="2013-03-20.3"
+ or
+ BUILD_ID=201303203.
+
+
+
+
- If you interpreting this file from code or a
- shell script, use the ID and VERSION_ID fields. When
- looking for an OS identification string for
- presentation to the user use the PRETTY_STRING
- field.
+ If you are reading this file from C code or a
+ shell script to determine the OS or a specific version
+ of it, use the ID and VERSION_ID fields, possibly with
+ ID_LIKE as fallback for ID. When looking for an OS
+ identification string for presentation to the user use
+ the PRETTY_NAME field.
Note that operating system vendors may choose
not to provide version information, for example to
- accommodate for rolling releases. In this case VERSION
+ accommodate for rolling releases. In this case, VERSION
and VERSION_ID may be unset. Applications should not
rely on these fields to be set.
+
+ Operating system vendors may extend the file
+ format and introduce new fields. It is highly
+ recommended to prefix new fields with an OS specific
+ name in order to avoid name clashes. Applications
+ reading this file must ignore unknown fields. Example:
+ DEBIAN_BTS="debbugs://bugs.debian.org/"
Example
NAME=Fedora
-VERSION=15 (Rawhide)
+VERSION="17 (Beefy Miracle)"
ID=fedora
-VERSION_ID=15
-PRETTY_NAME=Fedora 15 (Rawhide)
-ANSI_COLOR=0;34
+VERSION_ID=17
+PRETTY_NAME="Fedora 17 (Beefy Miracle)"
+ANSI_COLOR="0;34"
+CPE_NAME="cpe:/o:fedoraproject:fedora:17"
+HOME_URL="https://fedoraproject.org/"
+BUG_REPORT_URL="https://bugzilla.redhat.com/"
See Also
systemd1,
- lsb_release1
+ lsb_release1,
+ hostname5,
+ machine-id5,
+ machine-info5