From owner-freebsd-questions@FreeBSD.ORG Fri May 4 14:45:27 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B63451065673 for ; Fri, 4 May 2012 14:45:27 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 615B98FC12 for ; Fri, 4 May 2012 14:45:27 +0000 (UTC) Received: from r56.edvax.de (port-92-195-20-192.dynamic.qsc.de [92.195.20.192]) by mx02.qsc.de (Postfix) with ESMTP id BEFEF1EB3B; Fri, 4 May 2012 16:45:19 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q44EjJkQ001930; Fri, 4 May 2012 16:45:19 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Fri, 4 May 2012 16:45:19 +0200 From: Polytropon To: Robert Bonomi Message-Id: <20120504164519.d04ba910.freebsd@edvax.de> In-Reply-To: <201205040914.q449E5iZ037677@mail.r-bonomi.com> References: <4FA38AB8.7010806@infracaninophile.co.uk> <201205040914.q449E5iZ037677@mail.r-bonomi.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: freebsd-update not updating reported patchlevel X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:45:27 -0000 On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote: > What is required is a differentation between the _kernel_ revision level, > and the patchlevel of the entire base system. > > Store the kernel revision level -in- the kernel. Use the 'standard' > THREE-level version numbering {Major}.{Minor}.{revision} for the kernel. > Bump 'revision' for each set fo kernel patches. > > The patchlevel info for the base system can be a simple data file. > I'd suggest a dotfile' in /etc, mode 644, with the followig flags > set: 'system append only', 'system undlink'. > > Bump 'patchlevel' every time -anything- in the base system changes, > regardless of whether it is part of the kernel or the 'world'. Interesting approach. Both files could also be header files in /usr/include to store this information per #define. But in fact, I like the /etc idea better. 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. :-) > Both kernel revision level and 'world' patchlevel are reset -only- > when a new minor (or major) release of the O/S is installed. Aside > from that, they increment semi-independantly -- 'world' patchlevel > is always greater-equal to kernel revision level. > > Ideally, this is a _log_ of all the actual changes, something along the > lines of: > > BEGIN updates > updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced > patchfile {foo1} for {pathname}, patch application succeeded > patchfile {foo2} for {pathname}, patch application FAILED > obselete file {foo3} renamed to {foo3}.x.y.z-obselete > END updates Now at patchlevel {quux} > > For 'audit' purposes', every line is prefixed with > timestamp, > login username/effective UID(as a username) > the tty device from which the action was performed. > > When a new release of the O/S is installed, the patchlog file is renamed > or deleted, and a single line of the form: > > END install Now at patchlevel 0 > > is written. Thus there is always an END line with the patchlevel ID. > > The numeric patchlevel is written as a fixed-width *right-justiied* field. > > Thus, the last 'END' starts at a 'known' position before the end of the > file, allowing an application to do a direct fseek(3)/lseek(2) to it (or > the patchlevel) without having to read the entire file. ('install' and > 'updates' are chosen with malice aforethought, they're the same length ;) > > From the command-line, 'tail -1 {patchlog}' gets everything. Also very nice. By simply _viewing_ the file, the most non-current version will be discovered, so maybe (just _maybe_) re-ordering them in upside-down (newest version on top) would be better? Of course, this would not go well with the "log idea". Files like UPDATING in the /usr/ports and /usr/src tree use such an approach. Such a log file would not feel comfortable in /etc, it should rather go to /var or even /var/log. :-) > With this kind of setup, and assuming that all distributed patchfiles have > 'unique' names, the 'patchlog' provides a roadmap for reconstructing the > state of the kernel and 'world' as of any particular point in time. > > AT LEAST as important, it provides a record that would let one 'back out' > an update, to revert to a prior system state, if needed. In fact, it > would be 'easy' to have automation perform that task. How about performing "version skips", e. g. from -p1 to -p4 directly (using freebsd-update), or wider steps, e. g. from 8.3 to 8.4 (using sources per CVS)? -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...