Create /etc/os-release file.

[imp]

Summary

Each boot, regenerate /var/run/os-release based on the currently running
system. Create a /etc/os-release symlink pointing to this file (so that this
doesn't create a new reason /etc can not be mounted read-only).

This is compatible with what other systems do and is what the sysutil/os-release
port attempted to do, but in an incomplete way. Linux, Solaris and DragonFly all
implement this natively as well. The complete standard can be found at
https://www.freedesktop.org/software/systemd/man/os-release.html

Moving this to the base solves both the non-standard location problem with the
port, as well as the lack of update of this file on system update.

PR: 238953

[brooks]

libexec/rc/rc.d/os-release

23 ↗

(On Diff #64031)

I'd use

VERSION_ID=${VERSION%%[^0-9.]*}

34 ↗

(On Diff #64031)

I'd tend to save a subshell and a bunch of quotes with a heardoc.

[cem]

Any reason to avoid generating to a temporary file first (possibly in tmpfs) and installing with install -C (i.e., don't re-write or bump mtime if the contents did not change)? Slightly more friendly to low-endurance media /var devices.

I support the general idea and have no objection to the implementation.

libexec/rc/rc.d/os-release

33 ↗

(On Diff #64031)

Suggest adding a canonical trailing "/" to BUG_REPORT_URL.

(Used to be "/bugzilla/" was required, but it seems we have a working redirect now, so "/" is fine.)

[imp]

update per cem and brooks

[rpokala]

and is what the
sysutil/os-release port.

E_GRAMMAR

[tcberner]

Thank you.

[se]

libexec/rc/rc.d/os-release

13 ↗

(On Diff #64062)

The value of $desc could take a user-defined setting of $osrelease_file into account if moved down 4 lines (or if setting default values for osrelease_file and os_release_perms was moved up to above name=...)

[imp]

libexec/rc/rc.d/os-release

13 ↗

(On Diff #64062)

I'll include that in the next update. Thanks

[bapt]

To be clear, I am validating the content of the file and the principle of a rc.d. Now I am wondering it is won't be better served by a port/package as it has a niche usage anyway (for now at least), and that will make it cover all supported version of FreeBSD straight away.

It will still be possible to move it to base later if we have a real need for it in base in the futur

[manu]

Does that needs a exp-run too ?
I guess that some ports currently test if this file exists at configure step and don't depend on the current port so this might affect them.
I'd still like to know what ports currently need this too (at least the main one).

[tcberner]

In D22271#487097, @manu wrote:

Does that needs a exp-run too ?
I guess that some ports currently test if this file exists at configure step and don't depend on the current port so this might affect them.
I'd still like to know what ports currently need this too (at least the main one).

At the moment three ports explicitely use it:

• gnome uses it in sysutils/gnome-control-center
• every Qt5 application can use its information as it's available through devel/qt5-core and further in devel/kf5-kcoreaddons [2], [3], so for example kinfocenter uses the information provided.

I'm not aware of it being checked at configure stage by anything -- if this were the case however, it would be even more important for it to be in base :)

[1] https://github.com/GNOME/gnome-control-center/blob/1752cf3bb573d300e990ea10006dea70a322d8df/panels/common/cc-os-release.c#L45
[2] https://github.com/qt/qtbase/blob/dev/src/corelib/global/qglobal.cpp#L2270
[3] https://github.com/KDE/kcoreaddons/blob/master/src/lib/util/kosrelease.cpp#L87

[manu]

In D22271#487113, @tcberner wrote:

In D22271#487097, @manu wrote:

Does that needs a exp-run too ?
I guess that some ports currently test if this file exists at configure step and don't depend on the current port so this might affect them.
I'd still like to know what ports currently need this too (at least the main one).

At the moment three ports explicitely use it:

• gnome uses it in sysutils/gnome-control-center
• every Qt5 application can use its information as it's available through devel/qt5-core and further in devel/kf5-kcoreaddons [2], [3], so for example kinfocenter uses the information provided.

I'm not aware of it being checked at configure stage by anything -- if this were the case however, it would be even more important for it to be in base :)

[1] https://github.com/GNOME/gnome-control-center/blob/1752cf3bb573d300e990ea10006dea70a322d8df/panels/common/cc-os-release.c#L45
[2] https://github.com/qt/qtbase/blob/dev/src/corelib/global/qglobal.cpp#L2270
[3] https://github.com/KDE/kcoreaddons/blob/master/src/lib/util/kosrelease.cpp#L87

Thanks. So I guess that my next question is : how does this files affects those program ?
It is just cosmetic ? (like they will display FreeBSD instead of the default "Linux" string) or something else ?

[imp]

I'm not aware of it being checked at configure stage by anything -- if this were the case however, it would be even more important for it to be in base :)

clang uses it for various things (like directory paths if I'm reading the code correctly), though only for the Linux drivers...

[imp]

In D22271#487094, @bapt wrote:

To be clear, I am validating the content of the file and the principle of a rc.d. Now I am wondering it is won't be better served by a port/package as it has a niche usage anyway (for now at least), and that will make it cover all supported version of FreeBSD straight away.

It will still be possible to move it to base later if we have a real need for it in base in the future

It is already a port. The problem is that it's not updated with the base is updated so can be out of date in the information it supplies. The other problem is that the port installs it in a non-standard place and we patch all the programs in ports (that we catch) to use the non-standard path. So, between these two issues, I thought that it was time to migrate it into base, especially in light of DragonflyBSD creating and installing one as part of their installworld. Since we can't hack files in /etc, per long standing tradition, this was the next best way to conform to the standard.

[imp]

In D22271#487162, @manu wrote:

Thanks. So I guess that my next question is : how does this files affects those program ?
It is just cosmetic ? (like they will display FreeBSD instead of the default "Linux" string) or something else ?

It looks like it will display Linux, at the very least. This is bad for our branding efforts (FreeBSD isn't just a Linux distro). It's unclear if there are downstream users that use this value for other things. It will also not display version information. It makes the FreeBSD versions of programs look less professional and the integration hap-hazard and incomplete.

[imp]

For those that are interested, the DragonFly commit is here http://gitweb.dragonflybsd.org/dragonfly.git/commit/9c172c374855a49366c18d9b34b978ce87a7fa2b

[imp]

Also standard in Solaris, per bcran:

Also, it's enough of a standard that it's supported in Solaris 11.4 - https://docs.oracle.com/cd/E88353_01/html/E37852/os-release-5.html

Solaris 11.4 was released in October 2018.

[imp]

Update per review comments
Update etc/defaults/rc.conf

[imp]

In D22271#487097, @manu wrote:

Does that needs a exp-run too ?
I guess that some ports currently test if this file exists at configure step and don't depend on the current port so this might affect them.

It wouldn't hurt, though I'd omit it if we're running short on exp-run resources.

[trasz]

libexec/rc/rc.conf

681 ↗

(On Diff #64082)

Uppercase the 'Default'?

libexec/rc/rc.d/os-release

34 ↗

(On Diff #64082)

Should we perhaps follow the usual way of spelling our URL as FreeBSD.org?

[vangyzen]

It would be nice to include some documentation. The systemd man page seems most useful and canonical, but it's LGPL. Maybe include a link to it in a comment in the generated file?

libexec/rc/rc.d/os-release

24 ↗

(On Diff #64082)

s/motd/os-release/ ?

[imp]

More review commentary addressed.

[imp]

Now with freshly-written man page.

[imp]

In D22271#487273, @vangyzen wrote:

It would be nice to include some documentation. The systemd man page seems most useful and canonical, but it's LGPL. Maybe include a link to it in a comment in the generated file?

I wrote a man page instead :) It summarizes the standard.

[zeising]

Perhaps @bcr can have a quick look at the man page?

[lantw44_gmail.com]

In D22271#487113, @tcberner wrote:

At the moment three ports explicitely use it:

• gnome uses it in sysutils/gnome-control-center

GLib will have a new API called g_get_os_info to read /etc/os-release in the next stable release: https://gitlab.gnome.org/GNOME/glib/merge_requests/1063. gnome-control-center is likely switch to it because the API was proposed and implemented by a gnome-control-center maintainer. It is expected to see more and more GNOME applications using it because nearly all GNOME applications use GLib. I wrote a uname fallback for the function: https://gitlab.gnome.org/GNOME/glib/merge_requests/1165, so the situation isn't too bad on FreeBSD. At least it already reports correct name and version of FreeBSD kernel. It is nice to know that FreeBSD will have /etc/os-release and the fallback will not be needed.

[bcr]

Man page looks good to me.

[vangyzen]

Thanks for the man page!

[sef]

My only concern involves the /etc symlink possibly pointing at a non-existent file. This is a small concern not worth preventing this.

[0mp]

libexec/rc/rc.d/os-release

22 ↗

(On Diff #64090)

It is just a minor thing, but shouldn't we use local variables here like local _version to match other rc scripts?

share/man/man5/os-release.5

123 ↗

(On Diff #64090)

Wouldn't it be nice if we use the .Lk macros for links?