<refsynopsisdiv>
<para><filename>/etc/os-release</filename></para>
+ <para><filename>/usr/lib/os-release</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
- <para>The <filename>/etc/os-release</filename> file
- contains operating system identification data.</para>
+ <para>The <filename>/etc/os-release</filename> and
+ <filename>/usr/lib/os-release</filename> files contain
+ operating system identification data.</para>
<para>The basic file format of
<filename>os-release</filename> 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
+ 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
a-z, 0-9. All strings should be in UTF-8 format, and
non-printable characters should not be used. If double
or single quotes or backslashes are to be used within
- variable assignments they should be escaped with
+ variable assignments, they should be escaped with
backslashes, following shell style. It is not
supported to concatenate multiple individually quoted
strings. Lines beginning with "#" shall be ignored as
comments.</para>
- <para><filename>/etc/os-release</filename> contains
- data that is defined by the operating system vendor
- and should not be changed by the administrator.</para>
+ <para>The file <filename>/etc/os-release</filename>
+ takes precedence over
+ <filename>/usr/lib/os-release</filename>. Applications
+ should check for the former, and exclusively use its
+ data if it exists, and only fall back to
+ <filename>/usr/lib/os-release</filename> if it is
+ missing. Applications should not read data from both
+ files at the same
+ time. <filename>/usr/lib/os-release</filename> is the
+ recommended place to store OS release information as
+ part of vendor trees.
+ <filename>/etc/os-release</filename> should be a
+ relative symlink to
+ <filename>/usr/lib/os-release</filename>,
+ to provide compatibility with applications only
+ looking at <filename>/etc</filename>. A relative
+ symlink instead of an absolute symlink is
+ necessary to avoid breaking the link in a chroot or
+ initrd environment such as dracut.</para>
+
+ <para><filename>os-release</filename> contains data
+ that is defined by the operating system vendor and
+ should generally not be changed by the
+ administrator.</para>
<para>As this file only encodes names and identifiers
it should not be localized.</para>
- <para>The file <filename>/etc/os-release</filename> might
- be a symlink to another file, but it is important that
+ <para>The <filename>/etc/os-release</filename> and
+ <filename>/usr/lib/os-release</filename> 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.</para>
<para>For a longer rationale for
- <filename>/etc/os-release</filename> please refer to
+ <filename>os-release</filename> please refer to
the <ulink
url="http://0pointer.de/blog/projects/os-release">Announcement of <filename>/etc/os-release</filename></ulink>.</para>
</refsect1>
<title>Options</title>
<para>The following OS identifications parameters may be set using
- <filename>/etc/os-release</filename>:</para>
+ <filename>os-release</filename>:</para>
<variablelist>
<listitem><para>A string identifying
the operating system, without a
version component, and suitable for
- presentation to the user. If not set
+ presentation to the user. If not set,
defaults to
<literal>NAME=Linux</literal>. Example:
<literal>NAME=Fedora</literal> or
identifying the operating system,
excluding any version information and
suitable for processing by scripts or
- usage in generated file names. If not
- set defaults to
+ usage in generated filenames. If not
+ set, defaults to
<literal>ID=linux</literal>. Example:
<literal>ID=fedora</literal> or
<literal>ID=debian</literal>.</para></listitem>
<listitem><para>A space-separated list
of operating system identifiers in the
same syntax as the
- <varname>ID=</varname> setting. Should
+ <varname>ID=</varname> setting. It should
list identifiers of operating systems
that are closely related to the local
operating system in regards to
OS is a derivative from. An
OS should generally only list other OS
identifiers it itself is a derivative
- from, and not any OSes that
- are derived from it, but symmetric
+ 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
closest. This field is
optional. Example: for an operating
system with
- <literal>ID=centos</literal> an
+ <literal>ID=centos</literal>, an
assignment of <literal>ID_LIKE="rhel
fedora"</literal> would be
appropriate. For an operating system
- with <literal>ID=ubuntu</literal> an
+ with <literal>ID=ubuntu</literal>, an
assignment of
<literal>ID_LIKE=debian</literal> is
appropriate.</para></listitem>
system version, excluding any OS name
information or release code name, and
suitable for processing by scripts or
- usage in generated file names. This
+ usage in generated filenames. This
field is optional. Example:
<literal>VERSION_ID=17</literal> or
<literal>VERSION_ID=11.04</literal>.</para></listitem>
presentation to the user. May or may
not contain a release code name or OS
version of some kind, as suitable. If
- not set defaults to
+ not set, defaults to
<literal>PRETTY_NAME="Linux"</literal>. Example:
<literal>PRETTY_NAME="Fedora 17 (Beefy
Miracle)"</literal>.</para></listitem>
<listitem><para>A CPE name for the
operating system, following the <ulink
- url="http://cpe.mitre.org/specification/">Common
+ url="https://cpe.mitre.org/specification/">Common
Platform Enumeration
Specification</ulink> as proposed by
the MITRE Corporation. This field
<listitem><para>Links to resources on
the Internet related the operating
system. <varname>HOME_URL=</varname>
- should refer to the homepage of the of
+ should refer to the homepage of the
operating system, or alternatively
some homepage of the specific version
of the operating
URLs are intended to be exposed in
"About this system" UIs behind links
with captions such as "About this
- Operating System", "Obtain Support"
- resp. "Report a Bug". The values should
+ Operating System", "Obtain Support",
+ and "Report a Bug". The values should
be in <ulink
url="https://tools.ietf.org/html/rfc3986">RFC3986
format</ulink>, and should be
<literal>tel:</literal>. Only one URL
shall be listed in each setting. If
multiple resources need to be
- referenced it is recommended to
+ referenced, it is recommended to
provide an online landing page linking
all available resources. Examples:
<literal>HOME_URL="https://fedoraproject.org/"</literal>
<literal>BUG_REPORT_URL="https://bugzilla.redhat.com/"</literal></para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>BUILD_ID=</varname></term>
+
+ <listitem><para>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:
+ <literal>BUILD_ID="2013-03-20.3"</literal>
+ or
+ <literal>BUILD_ID=201303203</literal>.
+
+ </para></listitem>
+ </varlistentry>
</variablelist>
<para>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.</para>
~ianmdlvl / elogind.git / blobdiff