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 <http://www.gnu.org/licenses/>.
-->
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
<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 systemd
- with <literal>ID=ubuntu</literal> an
+ appropriate. For an operating system
+ 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>
+
+ <para>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:
+ <literal>DEBIAN_BTS="debbugs://bugs.debian.org/"</literal></para>
</refsect1>
<refsect1>