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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Reply via email to