On Friday, September 28, 2012 01:43:42 AM Lamar Owen wrote:
> ...
> > If you want the gory details, I'll be glad to share, but the short and sweet of it is that I now have one Altix box running my own local [partial] rebuild of CentOS 5.5 on ia64.
>
> I'm now dong a 'self-hosting' build of 5.5...
Ok, well, I've learned a lot since last Friday. Especially as it pertains to circular dependencies and how to properly (hopefully) step from one release up to another. While I still have 14 ia64-supported packages that aren't successfully rebuilding at the 5.5 level, I have enough of a fully built 5.5 tree, not fully self-hosted, but built, to try a run at building the 5.6 updates while I'm doing other things. Since I started that build, 18 builds have succeeded, producing 48 binary packages, and no builds have failed yet (I expect to see some failures, since I didn't prune the updates list of non-ia64-buildable packages). There aren't but 218 source packages to rebuild, so it shouldn't take more than overnight, I would think.
And I say 'ia64 supported' above for a reason. There are a number of packages that either don't have ia64 included or have ia64 specifically excluded, 47 of them in the 5.5 sources to be exact.
And I edited the above quote to better reflect the 'testing' 5.5 partial build to which I upgraded one box earlier.
My game plan is to use the nearly complete 5.5 tree to build the 5.6 updates, then use the 5.5 tree plus the 5.6 updates to build 5.7, and so on. Once a nearly complete 5.8 tree is built, I'll retry a self-hosting build of the complete 5.8 source package set using the 5.5+5.6updates+5.7updates+5.8updates trees to seed the buildroots, and then will build and mung things until a fully-self-hosted build is done. Mung is a highly descriptive piece of jargon for this process, being that 'mung' itself is a recursive acronym.... ('Mung until no good' as defined in the New Hacker Dictionary, aka the Jargon File).
And while it might seem like I could sidestep up to 5.8, I want to iterate through the whole process, using the full tree, for my own reasons.
This is certainly an iterative, and, at times, a hair-pulling process due to hidden and/or undocumented build requirements (upstream hidden and upstream undocumented; I've had to inject, using the chroot_setup_cmd macro in the mock config, a handful of packages that aren't listed as buildrequires: for packages that are being built). And that is somewhat frustrating!
And, again, the encouragement of and hints from Karanbir, Johnny, and Russ have been highly valuable.
But I want to note that I have done what I have done thus far using only publicly available information about the CentOS build process and my own knowledge of RPM building from my five years of maintaining the packages for PostgreSQL; it takes thought and iterative legwork to make this stuff rebuild. And I'm not using the centos-used version of mock, nor am I using any 'secret' configurations from the centos developers; just pointers to the right directions in general, which have been most helpful. And reading build logs and trying to ferret out why that package didn't build (was it the gcc version, or is there a missing dep, or do I need to turn off parallel builds, or....?).