On Sat, Mar 26, 2011 at 2:53 PM, Les Mikesell <lesmikes...@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. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
