Creating /etc/os-release

[Cy Schubert]

In message <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q at mail.gmail.c
om>
, Warner Losh writes:
> Greetings,
>
> 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 http://0pointer.de/blog/projects/os-release and
> here https://www.freedesktop.org/software/systemd/man/os-release.html . 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238953. 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
> https://reviews.freebsd.org/D22271 for the specifics. Comments about the
> code should go there, while comments about the plan should go here.

And, with pkgbase, assign it the actual release of the O/S so that we can 
do pkg info -aI | grep ... similar to rpm -aq | grep ... Why? Automation 
such as HP SA, Tower, cfengine, and others could be used to query package 
names in a mysql or Oracle database of packages. One could write an sql 
query to display all servers in a network with, for examle, package 
freebsd-12.1 (or whatever we choose to call it) installed.

Of course this wouldn't work with -current or -stable unless installworld 
generates the appropriate package registrations at the time. Users of 
binary releases based on -RELEASE might see immediate benefit though. This 
might help integration into large shops -- making FreeBSD more visible to 
shops at the enterprise level -- which use that sort of automation.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.