On 03/10/2011 08:30 PM, Trent Johnson wrote: > On Thu, Mar 10, 2011 at 6:18 PM, Johnny Hughes <johnny at centos.org> wrote >> >> We do not change what upstream has in their SRPMS (except when we have >> to) ... we don't even unpack them unless we need to change them. We >> submit them to mock to build. Every patch we create, every change we >> make, it is in the SRPM. >> >> Why is this so hard to understand? >> > > What are the differences (if any) between the build procedures > documented by Scientific Linux at the url below? > https://www.scientificlinux.org/distributions/6x/build/problembyrpm > The do not document a build process at that page, so I don't know. That page is the packages that they currently have problems with on their rebuild of EL6. They do document some of the actions that they used to get some of the things to build. Some of those actions may or may not produce differences between the upstream binaries and those files produced. In order to know that, I would need to grab all their RPMs and run compares against the upstream RPMs, then analyze it. That takes long enough to do when I do it to CentOS, so I have not done it for theirs. If I have something I can't get to build, I will grab their SRPM and RPM and diff their SRPM with the one from upstream to see what they did to it. I will also compare their RPMs to ours and/or upstream's to see if they are linked correctly. > Would Scientific Linux also be 100% binary compatible with upstream, > or are there other procedures followed by Centos to achieve the binary > compatibility goal? I don't know their procedures, but I can show you 2 packages in 5.6 on the CERN build where there is a problem right now ... because I looked at their RPMS yesterday to solve our problem. (Their RPMs and SRPMS did not help me, they had the same issue as ours). Here is the output of an issue in both libtevent and certmonger that is in the current CERN build: Differing package requirements: --- work/SL-req 2011-03-09 07:35:12.000000000 -0500 +++ work/RHEL-req 2011-03-09 07:35:12.000000000 -0500 @@ -41,7 +41,7 @@ libpthread.so.0(GLIBC_2.0) libsmime3.so libssl3.so -libtalloc.so.1 +libtalloc.so.2 libtevent.so.0 libxmlrpc.so.3 libxmlrpc_client.so.3 What does this mean, it means that the libtevent package and the certmonger package are linked against and use libtalloc-1.2.x and not libtalloc-2.0.x. Does this mean their packages for libtevent and certmonger will not work? Not really, they might work fine. They are not, however, binary compatible with upstream. How many other packages are like that ... I have no idea as I have not tested all their packages. I only test our packages. Do they test their packages for this? I don't know. Getting a package to build and getting to be binary compatible are not the same thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110311/4b0798b2/attachment-0007.sig>