Date: Fri, 8 Nov 2019 09:41:24 -0700 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Creating /etc/os-release Message-ID: <CANCZdfqOKDrhLFs%2B2-JS7X5LFWNB3ZXo7RLQSDkcFgUCqRn92A@mail.gmail.com> In-Reply-To: <201911080706.xA876tSG045063@slippy.cwsent.com> References: <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@mail.gmail.com> <201911080623.xA86NCcO070007@slippy.cwsent.com> <CANCZdfqBjTJLZZAAmyxW_JyMeDxBYwa15xaCUF0H7Oshe65%2BpQ@mail.gmail.com> <201911080706.xA876tSG045063@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 8, 2019 at 12:07 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > In message > <CANCZdfqBjTJLZZAAmyxW_JyMeDxBYwa15xaCUF0H7Oshe65+pQ@mail.gmail.c > om> > , Warner Losh writes: > > --000000000000c332a50596d00425 > > Content-Type: text/plain; charset="UTF-8" > > > > On Thu, Nov 7, 2019, 11:23 PM Cy Schubert <Cy.Schubert@cschubert.com> > wrote: > > > > > In message > > > <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@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. > > > > > > It seems like pkg info would need some careful thought to know what to > > report to maximize the benefits of the automation you want. It seems to > me > > you'd want more exact version info than what's customary for os-release. > It > > isn't clear to me the needs of this file from a compatibility with other > > systems standpoint match well with what rpm -aq reports that you'd like > pkg > > to report. It's a good idea, but I'm having trouble connecting the dots > > with the problem I'm trying to solve here. > > Using Red Hat as an example, IIRC they put the version.release numbers in > the package name, or in the case of CentOS, a build number, followed by > the > repo name (el7 -- which I think is redundant), followed by the arch. We > could have something like FreeBSD-12.1-r353000.amd64. If we want to > maintain repositories for 12-stable and 12.1-release then something like > FreeBSD-12.1.12S-r353000 for the -stable repo v.s. FreeBSD-12.1p3.12R for > the same package within the 12-release repo. > Yes. That makes sense. How much resolution do you want on the version. 12, 12.1, 12.1p3, 12.1-stable-r35300 are all refinements of that answer. What you need depends a lot on the question you are asking. "Is this 12 vs 13?" vs "Is my entire fleet running the latest 12.1.p3.netflix47 yet?" Both are legit questions, but have very different actions depending on the answers. This file is more for the former than the latter, but that doesn't invalidate the desire to ask the latter question. > We don't need to decide the composition of the package name here and now > but the folks working on pkgbase might want to have some input into this. > Personally, I'm not set on one package name v.s. another, as long as we > consider how we derive the file's package name in our installworld and > release process. Contrary to how we'd normally consider what to do, in > this > case how it's done is probably more important than what the name is, as > whatever decisions are made now in how we implement this, we will have to > live with those decisions in the future. At this point how we do it is > more > important than the composition of the package name itself. > > I'd invite the pkgbase team for their thoughts. > I would too. This is a very interesting area to both follow industry practice, and break from it when there's a compelling reason (like a well known problem to fix). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqOKDrhLFs%2B2-JS7X5LFWNB3ZXo7RLQSDkcFgUCqRn92A>