"Bruce A. Mah" wrote: > > > RC2 has additional changes, above and beyond a simple date tag > > > (see other post; I believe it was managed in P4, > > 5.0-RC2 was assembled out of CVS, not P4. Terry, please check your > facts before posting.
My bad; this was already corrected by another poster, who pointed out that P4 was used for the "developer prereleases", but that the RC was out of the CVS tree. I didn't think it needed pointing out again, but if you do... "The RC2 was cut from the CVS tree". > > > and you could > > > use _that_ to recover it). A tag, in this case, would only be > > > useful if the other RC2 changes (string changes, hacks to suppress > > > known bugs, etc., mostly) were made in a branch off the tag, in > > > the main source tree, rather than in P4. > > Once again, 5.0-RC2 didn't have a darn thing to do with P4. I'm also > unaware of any "other RC2 changes". I was under the impression that the version string carried "RC2" in it; I'm willing to be mistaken. I thought there were also manual additions to the CDROM, such that it wasn't a pure "built from source tree" thing. > > > My personal approach would be to use the souce tree from disk #2 > > > (if one was made for the 5.0-RC2 distributions) > > > > 5.0-RC2-i386-disc1.iso contains 75M of compressed src/ > > 5.0-RC2-i386-disc2.iso /usr/src is empty. > > Disk #1 should have various compressed subtrees of src/ compressed (for > use by sysinstall). Those should work well. What Terry may be > referring to is the fact that for full releases, disk #2 usually > contains a compressed copy of the CVS repository. Yes, and yes. The CVS tree on disk #2 is a compressed snapshot of the source tree at the time. It's much more useful than the sources on disk #1, both because you have to know what you are doing to use the source on disk #1, and because you can CVSup it, get a relatively small delta (so it doesn't take a long time), and pick up any fixes that happened after the RC2 was cut. For example, Kirk checked in a UFS panic fix right after RC2 was cut, that might be the panic in this thread. There's no way to know, though, until the person with the panic repeats their panic during upgrade into the kernel debugger, and asks it where the panic happened. Basically, we are getting into all this esoteric stuff because someone has a bug that the rest of us can't repeat, and the only way it's going to get fixed is if the person seeing it does some extra work. Arguably, for releases, there should probably be an image on the CDROMs that would never fit on a floppy, and has the debugger on it, with symbols in the kernel, to let people debug things like this. I expect if that ever happens, it won't be the default distribution, anyway. In any case, that's what we've been telling the guy to build, in order to debug his upgrade problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
