From owner-freebsd-questions@FreeBSD.ORG Fri May 4 16:50:43 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A4A1065670 for ; Fri, 4 May 2012 16:50:43 +0000 (UTC) (envelope-from DStaal@usa.net) Received: from mail.magehandbook.com (173-8-4-45-WashingtonDC.hfc.comcastbusiness.net [173.8.4.45]) by mx1.freebsd.org (Postfix) with ESMTP id 72A688FC1C for ; Fri, 4 May 2012 16:50:43 +0000 (UTC) Received: from www.magehandbook.com (archersrock.info [192.168.1.100]) by mail.magehandbook.com (Postfix) with ESMTP id 3VkfNr64Ngzs6 for ; Fri, 4 May 2012 12:50:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 May 2012 12:50:36 -0400 From: Daniel Staal To: Mail-Reply-To: In-Reply-To: <20120504164519.d04ba910.freebsd@edvax.de> References: <4FA38AB8.7010806@infracaninophile.co.uk> <201205040914.q449E5iZ037677@mail.r-bonomi.com> <20120504164519.d04ba910.freebsd@edvax.de> Message-ID: <5185f3974780d202f94939293ef65396@mail.magehandbook.com> X-Sender: DStaal@usa.net User-Agent: Roundcube Webmail/RCMAIL_VERSION Subject: Re: freebsd-update not updating reported patchlevel X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: DStaal@usa.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 16:50:43 -0000 On 2012-05-04 10:45, Polytropon wrote: > Allow me to extent the approach: For -STABLE versions (e. g. if > updated per CVS), those files could contain the "build number" > and the date of the currently installed -STABLE "snapshot". > > A separation of a "kernel version file" and a "world version > file" is useful in cases the kernel won't be touched, so no > need to update its version file (as well as the kernel itself) > by a binary update. > > The files should be easily parsable. They could even contain > an assignment in sh syntax, as well as comments (for BSDL and > $FreeBSD$ information). Their templates could be stored in > the /usr/src subtree for the etc/ structure, so programs like > "make" and "mergemaster" could access them from there. > > Maybe a binary command could be added to the base system to > query this information (maybe "getent" could do that?). > > Here are some suggestions: > > /etc/kernversion > VERSION="8.2" > BRANCH="STABLE" > BUILD="12345" > DATE="2011-08-01 12:34:56" > > or > > /etc/kernversion > VERSION="8.4" > BRANCH="RELEASE" > PATCH="2" > DATE="2012-02-02 02:02:02" > > /etc/sysversion > VERSION="8.4" > BRANCH="RELEASE" > PATCH="4" > DATE="2012-04-04 04:04:04" > > This shows: Kernel has last been updated to patchlevel 2 (to > check with "uname -r" will show that version), but the system > has been updated two more times to patchlevel 4. > > The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations, > and X.Y-B for -STABLE installations. However, it's not hard to > write any custom "parser and composer" if urgently needed. > > Maybe things also present in "uname -a" output (such as architecture > and OS name) could be included, but I think that's not required > because it's mostly obvious. :-) I think you could still get a machine-parseable version on one line, that's also a bit nicer for human reading. Perhaps something like this? (Partly inspired by RedHat's /etc/redhat-release) /etc/sysversion FreeBSD RELEASE 8.4-p4: 2012-04-04 04:04:04 You should be able to parse that with a few lines of C or shell, and it looks like something set up to be read by humans. You just need to define - and stick to - which pieces of information will be in there in what order. (For instance, I'd prefer '9.0-p0' to '9.0' Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------