freebsd-update not updating reported patchlevel

Fri May 4 17:30:13 UTC 2012

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

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

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