Date: Thu, 7 Nov 2019 22:14:06 -0700 From: Warner Losh <imp@bsdimp.com> To: MJ <mafsys1234@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: Creating /etc/os-release Message-ID: <CANCZdfpR0yVXJvbCC9SKME-GpQwbOk5f5yv1%2Bjp2NzZ8M=Kbqw@mail.gmail.com> In-Reply-To: <cc85a07c-d272-8cf3-52ff-af608d08c9c9@gmail.com> References: <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@mail.gmail.com> <cc85a07c-d272-8cf3-52ff-af608d08c9c9@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 7, 2019, 3:39 PM MJ <mafsys1234@gmail.com> wrote: > > On 8/11/2019 5:10 am, Warner Losh wrote: > > 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. > > First off, I'm not attempting to be antagonistic about this, I have no > horse in this race. However, I am genuinely curious about why this is > needed and to that end why it adds more clutter to the system. > > So, forgive me, but why is this needed? Ok, it's a "standard" but for what > reason is there to add it specifically to FreeBSD? > FreeBSD implements industry standards. This is a new standard that creates friction for our users because they have to do extra things that users of other systems get without doing anything. > > 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. > > I see one issue. The issue is with the port itself, not FreeBSD. Does > FreeBSD fail to operate with this file missing? What ports are failing with > this missing? > Lots of desktop programs have issues. In my own use cases, our servers run fine without it. My desktop runs fine > without it. I'm not seeing the compelling reason. Sorry. > You can ignore it. I'm sure there are at least 2 extra firewalls you are ignoring or doing something to disable... > 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. > > So, the file is not needed, it will be nice to have, but I still can't see > a compelling reason to have it. > You are free to set osrelease_enable=NO in /etc/rc.conf if you don't want it. Just because it's a "standard" in Linux doesn't offer up to me a compelling > reason for its integration into the system. > It is standard on other systems. It causes friction to our users because we don't have it. It fits best into the base due to the location and the need to update when we update the system. Warner I am keen to hear those reasons; genuinely. > > Regards > > Mark > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpR0yVXJvbCC9SKME-GpQwbOk5f5yv1%2Bjp2NzZ8M=Kbqw>