Date: Tue, 18 Dec 2012 17:13:55 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: David Demelier <demelier.david@gmail.com> Cc: "C. P. Ghost" <cpghost@cordula.ws>, freebsd-questions@freebsd.org, "Anders N." <wicked@baot.se> Subject: Re: svn revision in uname Message-ID: <441uent3do.fsf@lowell-desk.lan> In-Reply-To: <CAO%2BPfDfP=28u_mBoG=1sOeghrPDqv8r4vBDqRrJs-CHcTjKDuw@mail.gmail.com> (David Demelier's message of "Mon, 17 Dec 2012 14:13:11 %2B0100") References: <20121215194427.GA19347@baot.se> <44txrnqbav.fsf@lowell-desk.lan> <CAO%2BPfDfP=28u_mBoG=1sOeghrPDqv8r4vBDqRrJs-CHcTjKDuw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Demelier <demelier.david@gmail.com> writes: > > 2012/12/15 Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> > >> "Anders N." <wicked@baot.se> writes: >> >> > Hi. I've noticed in my "uname -a" on 9.1-RELEASE there is "r243826." >> > This is on a system that upgraded from 9.1-RC3 using freebsd-update >> > (binary). On another system, upgraded from 9.0-RELEASE via >> > freebsd-update (source), there is nothing at all and uname -a looks >> > normal. Two other people I asked have r243825 (installed from ISO) and >> > r243872 (upgraded from svn). >> > >> > They're all 9.1-RELEASE, shouldn't they be the same, final version? >> >> As I understand it, the revision ID refers to the whole repository, not >> just a branch. So if you do your own svn checkout tomorrow, you'll get >> yet another revision number, even though the files will (probably) be >> completely identical to what you checked out yesterday -- ongoing >> commits to HEAD will keep kicking the revision number up. >> >> There is work going on to make system builds completely, bit-for-bit, >> repeatable, but that will presumably mean getting rid of this revision >> number information, not making it consistent. > I hope it will be removed soon, it pollutes the uname -a output. It's easy enough to add a stage in the kernel build to remove it if you don't like it, but in most source-update environments it's a very valuable piece of information. Even if a reproduceable-build infrastructure is put in place, it would have to be optional because this information is necessary in heterogeneous environments. I don't know that anyone's working on it the moment -- I *thought* I'd read something about it recently, but I can't find any reference to such an effort this year.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?441uent3do.fsf>