[CentOS-devel] Updates from today

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-0001.sig>