On Sat, Mar 26, 2011 at 2:53 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On 3/26/11 12:44 PM, Lamar Owen wrote: >> >> Les, the upstream source RPMs aren't even the "source source" for the upstream build; SRPMS are just a by product of the build of the binaries from source in an SCM (managed by Red Hat's koji), and in theory, given the same identical environment that built the upstream binaries they will re-build to the same binary. The environment is the hard thing to replicate, since it is a moving target, and each build changes it slightly. It's questionable if upstream could exactly replicate it from their own source RPM's without significant effort (that is, outside of koji). > > I don't see how you could miss if you did a 2nd rebuild where the libraries > populating the build environment are the product of the source you are shipping > (correct dependency listings or not). Or how you can claim to be shipping > source that matches your binaries if you don't do it that way. 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? "rpmbuild --rebuild" need not work. Dependencies need not be satisified by anything Red Hat publishes, and this has happened and been documented (and addressed in patches upstream). I went slightly nutso with similar issues when I published an updated "nx.spec" for CentOS 6 in Bugzilla. There are dependencies on audio related "devel" packages which are not on RHEL 6.0 installation media, but only available in the "optional" channel of yum-rhn-plugin. CentOS, sensibly, doesn't make these funny distinctions and puts all such publicly licensed packages in one main "os" repository. This can save a lot of nuttiness when trying to build such packages in mock, but for a while there I thought they hadn't published the darn thing.