X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=man%2Fos-release.xml;h=31dfe0ddf21421019f4b1ef86d1cbbbc587c1340;hp=d714b51fba7bea7a35ad20f1aa68302ed99d4f2e;hb=72b7d998059869942da8d540b7fe2c341225f91e;hpb=e9dd9f9547350c7dc0473583b5c2228dc8f0ab76 diff --git a/man/os-release.xml b/man/os-release.xml index d714b51fb..31dfe0ddf 100644 --- a/man/os-release.xml +++ b/man/os-release.xml @@ -1,7 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - - os-release - systemd - - - - Developer - Lennart - Poettering - lennart@poettering.net - - - - - - os-release - 5 - - - - os-release - Operating system identification - - - - /etc/os-release - - - - Description - - The /etc/os-release file - contains 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 - (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. - - /etc/os-release contains - data that is defined by the operating system vendor - and should not be changed by the administrator. - - As this file only encodes names and identifiers - it should not be localized. - - The file /etc/os-release might - be a symlink to another file, 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 - /etc/os-release please refer to - the Announcement of /etc/os-release. - - - - Options - - The following OS identifications parameters may be set using - /etc/os-release: - - - - - NAME= - - A string identifying - the operating system, without a - version component, and suitable for - presentation to the user. If not set - defaults to - NAME=Linux. Example: - NAME=Fedora or - NAME="Debian - GNU/Linux". - - - - VERSION= - - A string identifying - the operating system version, - 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 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. 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 - from, and not any OSes that - are derived from it, but 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, 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. - - - - PRETTY_NAME= - - A pretty operating - system name in a format suitable for - 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 - PRETTY_NAME="Linux". Example: - PRETTY_NAME="Fedora 17 (Beefy - Miracle)". - - - - ANSI_COLOR= - - A suggested - presentation color when showing the - 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. 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 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 - 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 + + os-release + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + os-release + 5 + + + + os-release + Operating system identification + + + + /etc/os-release + /usr/lib/os-release + + + + Description + + 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 (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 + os-release: + + + + + NAME= + + A string identifying the operating system, + without a version component, and suitable for presentation to + the user. If not set, defaults to + NAME=Linux. Example: + NAME=Fedora or NAME="Debian + GNU/Linux". + + + + VERSION= + + A string identifying the operating system + version, 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 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, 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. + + + + PRETTY_NAME= + + A pretty operating system name in a format + suitable for 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 + PRETTY_NAME="Linux". Example: + PRETTY_NAME="Fedora 17 (Beefy + Miracle)". + + + + ANSI_COLOR= + + A suggested presentation color when showing + the 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. 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= + PRIVACY_POLICY_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. + PRIVACY_POLICY_URL= should refer to the + main privacy policy page for the operation system, if there is + any. 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", + "Report a Bug", or "Privacy Policy". 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, + 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 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="17 (Beefy Miracle)" ID=fedora VERSION_ID=17 @@ -356,17 +311,17 @@ 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, - hostname5, - machine-id5, - machine-info5 - - + + + + See Also + + systemd1, + lsb_release1, + hostname5, + machine-id5, + machine-info5 + +