Date: Thu, 25 Apr 2013 13:43:03 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: FreeBSD-update? Message-ID: <5178A647.4030302@herveybayaustralia.com.au> In-Reply-To: <201304242332000938.0324FC0A@sentry.24cl.com> References: <201304242307.r3ON7AEg039368@chilled.skew.org> <201304242232170093.02EE4C98@sentry.24cl.com> <20130425044744.3ebda15f.freebsd@edvax.de> <201304242332000938.0324FC0A@sentry.24cl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/25/13 13:32, Mike. wrote: > On 4/25/2013 at 4:47 AM Polytropon wrote: > > |On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote: > |> If uname -r [-a] does not give the proper version of the OS, then it > is > |> either a bug, or the documentation for uname should be changed. > |> Currently, the man page for uname gives the following option: > |> > |> -r Write the current release level of the operating system to > |> stan- > |> dard output. > | > |Also the manpage of uname(3) would require a change to make clear > |that the version of the _kernel_ is provided, which _may_ stay the > |same during patchlevels of a given version. From that point of > |view, if we consider the patchlevel _not_ being part of the OS > |_version_, the statement (as it currently reads) makes sense. > |The understanding is: Version 9.1 is the OS version, and if > |a patch has been added, it's still 9.1 (even though the more > |precise information is 9.1-p5 for example). Similarly consider > |followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being > |reported, because no "precise" version numbers exist on that > |branch (at least not in the terms of patchlevels, instead a > |repository revision number or the date of the checkout could > |be considered for precision). > | > |The uname program relies on the uname system call to get the > |system identification, which queries the information stored in a > |(struct utsname *) data structure: > | > | The uname() function stores NUL-terminated strings of information > |identi- > | fying the current system into the structure referenced by name. > | > | > | The utsname structure is defined in the <sys/utsname.h> header > file, > |and > | contains the following members: > | > | release Release level of the operating system. > | > | version Version level of the operating system. > | > |This part of documentation would, given the case, also require > |adjustment, refering to the kernel instead of the OS. > ============= > > > On the other hand, maybe instead of changing the documentation of uname > to accommodate a problem with freebsd update, maybe freebsd update > should be changed to accommodate the historical and expected > performance of uname. > > In other words, once I found out this problem with freebsd update > (i.e., not properly refreshing the OS version), I stopped using it, as > I was not able to ascertain the current state of my OS installation > anymore. Interesting. My only observation was that sysctl is supposed to be the 'system' database where all queries relate to. It is supposed to display everything about the system; therefore any of these data bits should be fixed here first. Anything else would be a 'feature' :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5178A647.4030302>