X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fos-release.xml;h=b2983049432bbb29f2fcac14f0b433ceb192b9f3;hp=7f7ce142e0312db067903118357936c5f00da672;hb=e0104622b33f39ea8fd54f0a286d938401c08e3d;hpb=f8045772bd4e555a486fc9f440c80c9fad006fb7 diff --git a/man/os-release.xml b/man/os-release.xml index 7f7ce142e..b29830494 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,34 +49,82 @@ /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. + 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 should be enclosed + in double or single quotes if they include spaces, + semicolons or other special characters outside of A-Z, + 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 + backslashes, following shell style. 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: @@ -86,7 +134,7 @@ 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 NAME=Linux. Example: NAME=Fedora or @@ -99,27 +147,70 @@ A string identifying the operating system version, - excluding any OS name information, and - suitable for presentation to the - user. This field is optional. Example: + 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)". + 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 or usage in - generated file names. If not set - defaults to + (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 or + usage in generated filenames. If not + set, defaults to ID=linux. Example: - ID=fedora. + 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. @@ -130,9 +221,9 @@ characters outside of 0-9, a-z, ".", "_" and "-") identifying the operating system version, excluding any OS name - information or release code names, and + 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: VERSION_ID=17 or VERSION_ID=11.04. @@ -144,11 +235,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 PRETTY_NAME="Linux". Example: - PRETTY_NAME="Fedora 17 - (Beefy Miracle)". + 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)". @@ -156,7 +248,7 @@ 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 @@ -173,7 +265,7 @@ A CPE name for the operating system, following the Common + url="https://cpe.mitre.org/specification/">Common Platform Enumeration Specification as proposed by the MITRE Corporation. This field @@ -181,19 +273,99 @@ 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 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. When looking - for an OS identification string for presentation to - the user use the PRETTY_NAME field. + 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/" @@ -202,10 +374,12 @@ NAME=Fedora VERSION="17 (Beefy Miracle)" ID=fedora -VERSION_ID=15 +VERSION_ID=17 PRETTY_NAME="Fedora 17 (Beefy Miracle)" ANSI_COLOR="0;34" -CPE_NAME="cpe:/o:fedoraproject:fedora:17" +CPE_NAME="cpe:/o:fedoraproject:fedora:17" +HOME_URL="https://fedoraproject.org/" +BUG_REPORT_URL="https://bugzilla.redhat.com/"