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 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
<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