Creating /etc/os-release

Warner Losh imp at
Thu Nov 7 18:10:52 UTC 2019


A standard has evolved in other communities to communicate certain key
aspects of the system to interested parties.  The /etc/os-release file. The
standard is defined here and
here . It
has become a de-facto standard for the graphical systems.

FreeBSD currently tries to address this with a port
sysutils/etc_os-release, but there's a number of issues with it, see for
example The
biggest issue being that we can't install a static file: it has to change
as the system is updated.

To that end, I propose the following: First, we create a /etc/os-release
symlink to /var/run/os-release. This will place the file in the standard
place, but allow its generation on each boot in a friendly to
read-only-root manner. Second, we create a /etc/rc.d/os-release script that
will populate /var/run/os-release. Since this is a standard rc script, we
can allow people to opt-out of generating this file in a standardized way
(although it contains information that's available to anybody on the
system, some reduced configurations may not have all the scripts / programs
used to generate it). If the file isn't generated, then opening it will
return the same not found error as before. Since this is a symlink, it's
friendly to etcupdate / mergemaster updating schemes. Finally, we'd
obsolete the port since it is flawed anyway.

I opted for every boot rather than a file in /etc that gets generated as
part of mergemaster / etcupdate because it's more robust (the change
happens right away, and works in all environments, even if /etc isn't
updated). The amount of work here is tiny as well, so all but the most
demanding of users won't notice it at all. While this does come from the
Linux community, it has become a de-facto standard. DragonflyBSD has it,
for example, since 9c172c37, but their implementation is flawed for us to
use directly since it creates it at installworld time and we don't touch
/etc as part of installworld. We also have a port, but there's enough flaws
in the port approach that we should just make this be part of the base
system to place nicely with software that expects it today. It also means
we don't need hacks for freebsd-update. Finally, since this change is
additive, we can also MFC it to 12.

I've created a change that I think covers all these aspects. Please see for the specifics. Comments about the
code should go there, while comments about the plan should go here.


More information about the freebsd-arch mailing list