On Mon, 3 Nov 2025 22:57:43 GMT, Sergey Bylokhov <[email protected]> wrote:
>> That is a recommendation for Linux vendors on how to organize systemd >> related data - but we are not Linux vendors. We are on the side of >> application so we should check /etc as the documentation dictates. Because >> vendors can disobey the vendor side recommendation and put it... somewhere, >> like in /proc/systemd to be generated instead of static file. > >> Because vendors can disobey the vendor side recommendation and put it... >> somewhere, like in /proc/systemd to be generated instead of static file > > That is not. According to the specification, only two files are defined: >>The /etc/os-release and /usr/lib/os-release files contain operating system >>identification data. > > One of them is the primary file, while the other "optional" and exists only > for compatibility. And for the application - and we are an application - the same documentation says to look at the primary file location - in /etc. And only fall back to the second location if that file does not exist. If the file in /etc exists and differs from the /usr/lib/ file the later should not be used. Which implies that system vendor **can** replace the /etc/os-release file with another one or with link to the place other than /usr/lib/os-release. The /usr/lib/os-release is a fallback location. But we already have a fallback mechanics - we will have generic values set (osName is "Linux" and osVersion id null). Lust look at the usage examples at the bottom of the man page - all examples are using /usr/lib/os-release if /etc/os-release does not exist. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488141977
