Date: Fri, 4 May 2012 19:40:05 +0200 From: Damien Fleuriot <ml@my.gd> To: Polytropon <freebsd@edvax.de> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>, Robert Bonomi <bonomi@mail.r-bonomi.com> Subject: Re: freebsd-update not updating reported patchlevel Message-ID: <F2EF6614-21E4-4BE2-9A22-72B4486EA55A@my.gd> In-Reply-To: <20120504164519.d04ba910.freebsd@edvax.de> References: <4FA38AB8.7010806@infracaninophile.co.uk> <201205040914.q449E5iZ037677@mail.r-bonomi.com> <20120504164519.d04ba910.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 May 2012, at 16:45, Polytropon <freebsd@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.
>>=20
>> 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.
>>=20
>> 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'.
>>=20
>> Bump 'patchlevel' every time -anything- in the base system changes,
>> regardless of whether it is part of the kernel or the 'world'.
>=20
> 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.
>=20
> 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".
I have massive love for this idea, having to check the kern build date to ha=
ve a rough idea of what 8-STABLE I'm running is too prone to errors.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2EF6614-21E4-4BE2-9A22-72B4486EA55A>