RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names

Sergey Bylokhov serb at openjdk.org
Mon Nov 3 22:23:48 UTC 2025


On Mon, 3 Nov 2025 21:58:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 320:
>> 
>>> 318:         }
>>> 319:         try {
>>> 320:             File f = new File("/etc/os-release");
>> 
>> Don't we need to check "/usr/lib/os-release" as well?
>> https://www.freedesktop.org/software/systemd/man/latest/os-release.html
>>>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 that is missing. Applications should not combine the data from both files. /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.
>
> I'd considered that. Taking the wording above,  which encourages apps to check /etc first, and that every system I've checked has an /etc/os-release, and that it isn't a big deal even if we fail to find it unless you are creating a custom fontconfig file, I saw no need.

But still, according to that document, the correct location for storing the file is /usr/lib/os-release, while /etc/xx is only a compatibility workaround. Since we’ve already moved from an unspecified or non-standard behavior to the standard one, why not follow the specification completely?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2488027729


More information about the client-libs-dev mailing list