On Saturday, March 26, 2011 02:53:19 pm Les Mikesell wrote: > Does an > rpmbuild --rebuild of one of the packages in question on a stock RH system > create a binary that would fail the CentOS QA? This is the core of the question. As I don't have an RHEL 6 system available to try, I can't directly answer that. The answer is 'it depends'. But you still miss the issue; the buildroot repository is the binary tree built against, and it could contain binaries that are different from the shipped RHEL system's binaries. Of course, that's with mock, which makes it easier to make something that is not self-hosted; it also makes it possible to build multiple versions of systems on a single buildhost running yet a different version. Straight rpmbuild --rebuild may very well fail with missing build dependencies, which you would then have to go spelunking for in non-RHEL repositories (but they're out there, or SL6 wouldn't be built at all, now would it?). You have the exact source code used to build the package you have installed; you may or may not have all of the same versions of the dependencies that your binary package actually was built against. The question can be distilled as 'is RHEL self-hosting' to which the answer has been for a while 'No, and that isn't a primary goal of RHEL.' "Why not?" would be a reasonable question right about now. To use an example I work with, current Ardour 3 source code out of subversion (Ardour 3 is in alpha test, and is not released) cannot be compiled against just any version of the JACK development headers and libraries; to get a working executable, you have to compile against a specific version of the jack-devel package; but the built binary can run with any recent version of the JACK library. An Ardour 3 binary could be built and shipped that would work fine with the current JACK 1.96 but was built with 0.120.1 (which is the specific version required for the build to be successful). I would give you a link, but the current 'ardour-dev' archive is only available to members of that list. The point being, there are likely reasons other than carelessness or obfuscation-ness that a package might be built against development headers and libs that are different from the shipping versions (but with compatible sonames, perhaps), or maybe built with a different toolchain (compiler, linker, etc) than the shipping version of those tools, perhaps in order to just get the package to build; it will run fine with the shipping binaries, but may not build with them. And it may be a niche thing, where other packages in the distribution won't build with that particular toolchain.... I'll finish by pointing to the following resources for learning more about this (and I'm just throwing these out, I've not thoroughly checked everything said in these pages, but notice who is posting in some cases): http://adsm.org/lists/html/Veritas-bu/2010-07/msg00135.html http://www.redhat.com/archives/rhl-list/2004-January/msg02812.html http://www.redhat.com/archives/taroon-beta-list/2003-September/msg00038.html http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00072.html http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00073.html http://www.redhat.com/archives/nahant-list/2006-July/msg00059.html http://www.redhat.com/archives/taroon-list/2004-March/msg00249.html http://www.redhat.com/archives/taroon-list/2004-March/msg00261.html http://www.redhat.com/archives/nahant-list/2006-May/msg00266.html http://www.redhat.com/archives/nahant-list/2006-May/msg00264.html (side note on that last one.... there was and maybe still is a 'Cisco Enterprise Linux' build......reference: http://fr2.rpmfind.net/linux/RPM/sourceforge/p/project/pi/pipeviewer/OldFiles/pv-0.8.6-1.x86_64.html ) http://www.redhat.com/archives/taroon-list/2005-March/msg00222.html http://www.redhat.com/archives/taroon-list/2005-March/msg00228.html http://www.redhat.com/archives/nahant-list/2006-May/msg00273.html There are more.