freebsd-update not updating reported patchlevel

[Polytropon]

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