On Saturday, February 19, 2011 05:29:53 am Johnny Hughes wrote: > It is our goal to NOT HAVE ANY CHANGES. > Therefore a VCS at the package level for our projects is worthless [snip] > We do NOT change the packages (the SRPMS), therefore there is nothing > inside the packages to track. Whew. I understand this, for sure; but I think there is some cross-communication misunderstandings here. What I think most people are asking about is not the packages that are being built, and a VCS for the packages (if that's what they are wanting), well, I agree 100% that that is useless, since, as stated, to goal is the rebuild the completely unchanged source RPM and get the binary equivalent RPM out the backend. The SRPMS for the upstream components are already publicly visible at ftp.redhat.com. What I think folks are most interested in, and I know this is my case, is the versioning of the packages and changes (custom scripts, etc) to any packages on the buildhost that is doing the mock build itself. It's kindof like making sourdough bread (which I've done, using native yeast starter); the same set of ingredients, and the sourdough recipe is a well-known recipe, and pretty consistent from location to location, but yet the same ingredients using the same exact recipe can produce different results; it's all in the particular native yeast used for the starter, and the techniques used to get the starter started. That's why San Francisco sourdough bread tastes different from Western North Carolina sourdough bread; different yeasts. The upstream SRPMS are the ingredients, mock is the recipe; but what went into the starter? And, yes, sourdough starters are closely guarded secrets at bakeries that have unique products; similar is true for other yeast-driven ferments, including various alcoholic beverages made from fermented starches of various kinds. Which is why you can't make true scotch whisky anywhere but Scotland; it's all in the yeast, which is native. That's the part of the process that isn't externally open as far as I can tell. We have quite a bit of scattered documentation on the buildsystem, including mock configs, your scripts you posted a while back, etc. But the versioning of the buildhost (which, in theory shouldn't matter but in practice it does, especially for certain architectures like UltraSPARC) isn't well documented. At least I've not run across it; which is not the same thing as saying that it doesn't exist: it's just saying that I've not yet found it. To me, a simple 'rpm -qa|sort' output from the buildhost itself would answer a lot of my questions. I certainly would like to see that output for the IA64 buildhost, and for the last buildhost used for that one alpha SPARC build, as I would like to do those myself (getting C6 on UltraSPARC would be one of my end goals; there is a semi-usable F12-beta for SPARC, even though it's pretty broken for development purposes, meaning that the koji instance on the builder couldn't have been self-hosting and must be running something 'special'). But without knowing the packages and scripts on the buildhost and external to the SRPM repository to build I don't even know where to start, since I know a buildhost on SPARC requires some deep magic to set up (64-bit kernel but 32-bit userland; the buildhost has to be able to build a 64-bit kernel, and that isn't the easiest of tasks when the whole of userland is 32-bits, which makes sense pretty much only on SPARC, since 64-bit has no performance advantages on SPARC, just memory size advantages). I had a mutt setup on our E6500 at one time that began with Aurora 1.0 and went from there, using yum upgrades..... and replicating it would be a major undertaking. But that was the only SPARC build that I had here that would successfully build a kernel package set. So I'm off to investigate the Fedora buildhost documentation that I can find and go from there. (pointer for those who want to see 'square 1' for such: http://fedoraproject.org/wiki/Koji/ServerHowTo ) And this is really overkill infrastructure for a buildhost used for special purposes, I know, but at least it's a documented large-scale distributed buildsystem, and perhaps the key to understanding the whole thing resides somewhere in the reams of information out there)....and in no way am I implying that CentOS uses koji, just that a closely related project does (since Fedora is somewhat the upstream for RHEL). And, of course, getting an IA64 C6 (which might or might not be possible) would be something I'd love to try out, and is something I would want to do myself and not bother anyone else with; and if the results were something other people would want, then we could look at that when/if that arose. And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not automated...... And I'm not at all interested in 'competing' with the CentOS project; I don't have the bandwidth, for one, even if I do have the storage. But I certainly reserve the right to be wrong, on all counts.