freebsd-update not updating reported patchlevel

[Robert Bonomi]

Polytropon <freebsd at edvax.de> wrote:
>
> 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 <freebsd at edvax.de> 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<level> we currently are".
>
>     % uname -r
>     8.2-STABLE

"uname -v", maybe ??

> > /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.

Then it -definitely- doesn't belong in the 'include' hierarchy.  :)
/etc is the proper place.

> > *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).

An app generally only needs to know the version information about itself.
That info can be compiled in via proper use of CVS keywords.  The app can 
access the internal variables containing the compiled-in data and parse 
those 'known-format' strings to extract specific subfields..

If needed 'externally', then what(1), as I showed, can provide _lots_ of 
info about the executable.  You don't -need- an 'extended version' option,
or an 'about' screen. what(1) ("second base!" :) is all you need.

If one app is going to invoke another app, and needs to check version
'compatibility', then the app that is beinn invoked pretty much must
have a capability -- e.g. a '--version' option -- to report it's version.

If you're talking about trying to associate a particular patch/revison
level of a particular program with a partiular 'world' patchlevel.  That
is a very different problem, and requires a separate separate solution,
something like a 'correlation' database.

> 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?

For kernel info, any program that can 'popen' for write "uname -a".  *grin*
For the patchlevel of the 'world', TTBOMK it isn't recorded anywhere
conveniently accessible.  Thus the proposal for the /etc/{patchlog} file
with a specific 'well defined' format -- to provide *the* (single) 
'authoritative' place where such information is to be stored.


> 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<level> to -p<level+1> will leave the
> kernel's uname -r at -p<level>, so how to tell easily that
> the world is at -p<level+1>?

It doesn't presently exist.

That's precisely what the solution I proposed addresses.

In the complete solution I proposed, 
   'tail -1 /etc/{patchlog'

Or, for a program,
   one can popen() that command, and read the output
or even
    #include <sys/patchlog>
    #include <stdio.h>

    fd=fopen(PATCHLOG,"r");
    fseek(fd,PATCHLOG_LAST,SEEK_END);
    fgets(line,sizeof(line),fd)

> > 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.

If it's being done by automation, it can either log all the individual
'undo' changes, or just log a 'reverting to patchlevel {foo} line.
There are benefits to both approaches.

If it's a 'manual' reversion, there's no way to guarantee anything gets
added to the log.

> > 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. :-)
>
I used to do work for the financial/brokerage industry.  There is a saying
that "for any foolproof system there exists a _sufficiently_determined_
fool capable of breaking it."  I can state, from years of experience, that
that industry has a *LOT* of 'sufficiently determined' fools.  and it's
-never- their fault, and you have to fix it *IMMEDIATELY*, every second their
app is off line costs ${BIG_BUCKS}
>
>
> > 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.

Didn't claim you did. :) 

You asked a "what if", I just covered all the bases.

> > 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/eplacing 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.

I would *hope* so!!  *grin*
That was the problem that it was _designed_ to solve, after all..