From owner-freebsd-questions@FreeBSD.ORG Fri May 4 17:30:13 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 7F96A106566B for ; Fri, 4 May 2012 17:30:13 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 269608FC17 for ; Fri, 4 May 2012 17:30:13 +0000 (UTC) Received: from r56.edvax.de (port-92-195-20-192.dynamic.qsc.de [92.195.20.192]) by mx01.qsc.de (Postfix) with ESMTP id B286E3D003; Fri, 4 May 2012 19:30:05 +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 q44HU4NO002306; Fri, 4 May 2012 19:30:04 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Fri, 4 May 2012 19:30:04 +0200 From: Polytropon To: Robert Bonomi Message-Id: <20120504193004.c749ce16.freebsd@edvax.de> In-Reply-To: <201205041644.q44Gin2r041736@mail.r-bonomi.com> References: <20120504164519.d04ba910.freebsd@edvax.de> <201205041644.q44Gin2r041736@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 17:30:13 -0000 First of all, thanks for explaining your point of view. Allow me to add a few thoughts: On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote: > > Polytropon wrote: > > 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. > > The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be > included in kernal builds, and where the *handful* of utilities -- e.g. > lsof -- that are intimately coupled to the exact O/S version are already > picking up 'system specific' gory details. Correct. I appreciate the idea of having _one_ centralized point for that information that is "authoritative" regarding all queries. Like "uname" displays several aspects of the kernel's data, it is limited in some regards: For example, if you have updated the system the binary way to -p3 which included a kernel change, uname will report that -p3 properly. If you follow -STABLE, you don't get the information of what "build" you currently have, so you cannot put it into relation "after what -p we currently are". % uname -r 8.2-STABLE I know there is some file in /usr/src where the "build" number can be obtained from (I think it's a #define), but it's not included in the kernel "queryable" data. > /usr/include is definitely a 'wrong place'. Arguably, so is /etc. > From the standpoint of 'a single place' for critical data, anything other > than a kernel build should use what is in the 'uname' output. (See the > notes on O'Brien, below.) > > _Very_few_ applications are concerned with the patchlevel of 'world'. > rebuilding everything that #included a 'world patchlevel' file, when > the only thing that changed was the patchlevel, is just plain silly. Oh, I didn't think about recompiling any stuff "against" such a header file. I did primarily assume it as a kind of "purely informative source", which could also be provided by a plain text file. > *PROPERLY* USED, CVS keywords provide automatic inclusion of this > information -- for _every_ source module (.c or .h, and equivalents for > other languages) in every executable build. Correct, but obtaining such data is often not possible by the application itself (except it has an extended "version option" or it includes that info in a help screen). For the kernel, uname prints various information (which are obtained from the kernel directly, which is good), but what program can do the same for the system? > See above. > Done 'right', this stuff is already all there, with _existing- tools. Not fully, if I see it correctly. E. g., what "build" number has a particular -STABLE installation? Or, if kernel and world are able to be updated independently - no kernel change, but a program change from -p to -p will leave the kernel's uname -r at -p, so how to tell easily that the world is at -p? > > 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? > > Definitely -not-. > > You obviously didn't notice that the file flags are 'sysem append only'. Oh, I noticed that, and I know "appending on top" is always more complicated than appending (in the precise sense of what "to append" means). :-) > The entire point of my proposal is to make it an IMMUTATABLE RECORD of > 'what was done'. 'add to top' has several disadvantages. First, > a performance issue, you do have to read down the log to find the > first 'END' line rather than being able to seek directly to it. > Second, and the *BIG* one, you risk destroying the prior information > by re-writing the file. Third, it makes it easier for a 'malicious' > update to cover it's tracks. Additionally, _undoing_ operations would also be logged - not by omitting lines, but by a proper record that states how things have been reverted to a previous level, which is also very good for diagnostics. > Until you learn to "think like O'Brien", staying ahead of him requires a > -lot- of forethought. Oh, I often "think like O'Brien", and I don't remember, especially when I'm talking to 6079 Smith W., machen Sie die Augen auf! :-) On topic again: > When you learn to design stuff that _you_ can't break -- even if you are > deliberately trying -- life gets a lot easier. *GRIN* Very true. The idea of "proper append-only" and continuous logging is familiar to me in terms of database operations. Any state can be constructed from a proper log. In an extended approach, CVS uses the "only add information, not delete them" to manage versions, which is like "database, undelete, any version, progress meter and logging" all in one. :-) > If you do a direct update from -p1 to -p4, then when you 'unroll' the update, > you'd revert to -p1. No way to revert directly to -p3 -- you "don't know" > what changes were not in -p3. To go from -p4 to -p3 in that situation, you'd > have to revert to -p1, then apply -p3. That's the logical conclusion, I didn't argue against it. > As for an O/S minor-version (or major, for that matter) update, that is > outside the realm of a 'patchlevel management' system. Hopefully the version > upgrade process has its -own- provisions to (a) back up, and (b) *log*, what > is changed. Since that version upgrade process -would- involve changing/ > replacing the above-described 'patchlog', It would require a -minor- > additional tweak to back up 'obseleted' patchlog, in addition to the tweak to > install the new 'one-line' patchlog described above.. And it would solve the "controversy of kernel patch level vs. world patch level", and how to get the corresponding numbers. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...