Date: Fri, 31 Oct 2014 11:01:07 -0400 From: Mason Loring Bliss <mason@blisses.org> To: freebsd-questions@freebsd.org Subject: Whence RC4? Message-ID: <20141031150107.GY17150@blisses.org>
next in thread | raw e-mail | index | archive | help
I've been watching the update servers eagerly since the day RC4 was to begin
building, based on the schedule here:
https://www.freebsd.org/releases/10.1R/schedule.html
And yet, http://update.freebsd.org/10.1-RC4/ continues not to exist.
I haven't found a public releng coordination mailing list or any real
explanation of the process. Can someone enlighten me? The article
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html
talks about binary patchkits existing to match releng/x.y branches, but it
doesn't describe their creation or how such a process might differ for
release candidates.
While I'm interested in this, I've also got the secondary goal of exploring
how to move back to using binary patches and freebsd-update after having
built from source for a while. My home desktop is my test case, and it's
currently identifying itself as being 10.1-RC3, built from this at the right
time:
https://svn0.us-east.freebsd.org/base/releng/10.1
Something I'm not clear on is the possibility of finding a particular point
in time along a branch with Subversion, be it a tag or a date. I still think
in terms of CVS and that seems not to be valid when applied to SVN. It seems
like Subversion has 'svn up -r' to update to a particular revision number, or
a rough date specifier to update to "revision at start of the date".
How does FreeBSD deal with the lack of CVS-style tags? If one wanted to
recreate a 10.1-RC2 build, for instance, is there a sane way to do it, or
would it involve grovelling through commit logs for clues?
Anyway, my hope is to find the most reasonable way to build something that
freebsd-update will accept as a valid place from which to update. If this
ends up not actually being possible, I'll unroll tarballs to make my binaries
match, but it seems like it should be possible to have a more elegant
solution.
As a side note, it's unfortunate that freebsd-update.sh doesn't document what
the numeric parameters are in its explosion of little shell functions, which
would save finding and inspecting invocations. I'm finishing little traces
with "Oh, that ends up being a filename, but it's not entirely clear what's
supposed to be in the file." For instance, fetch_filter_mergechanges is only
called once, so its arguments are always going to be the same filenames, but
that's not documented, nor is there a stated convention suggesting that
particular numeric parameters always map to specific files. So, we end up
with things like this:
# For all paths appearing in $1 or $3, inspect the system
# and generate $2 describing what is currently installed.
fetch_inspect_system () {
It's just shy of being a useful comment at the start of the function. Anyway,
I mention all this because I was reading through the script to try to
ascertain how much it cares about whether or not my checksums all match,
since I'm building from source to start, and I got completely sidetracked
trying to understand the structure of the thing. It ends up having an
explosion of little shell functions, but then in parts it duplicates big
hunks of similar functionality for no obvious reason - compare IDS_run,
fetch_run, and upgrade_run for an example of this.
In short..... ¿Que?!?
--
Mason Loring Bliss (( If I have not seen as far as others, it is because
mason@blisses.org )) giants were standing on my shoulders. - Hal Abelson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141031150107.GY17150>