On Fri, Mar 25, 2011 at 6:26 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > On 3/25/2011 5:03 PM, Nico Kadel-Garcia wrote: >> >>>>> Or, maybe there was back in the days when they released source that >>>>> matched >>>>> their binaries >>>> >>>> Red Hat's published source is what they use to create their binaries. >>>> There is no mis-match. >>> >>> I thought the issue causing the delays is that rebuilding from the >>> source does not reproduce their binaries unless you introduce library >>> versions that aren't what the source creates. >> >> One has to be cautious about the bootstrap environment, to make sure >> that the libraries available in your "mock" or other build >> environments are the same libraries. Red Hat seems to be very, very >> good about this. > > It is not that they are good, they are the authority. Whatever library > version happened to be in their build root when the linkage was done is > correct by definition even if it isn't what you get when you build that > library from source and/or it isn't specified as a dependency. And they're very good about making sure that they've correctly "bootstrapped" their systems, that their "build" environment matches the components of the available, rebuilt packages. This was a deadly problem in the early days of compilers, when to build gcc, you basically had to build it *4* times to make sure the new gcc compiler was used to build the new gcc compiler, which rebuilt the gcc compiler, and then the fourth one was compared to the third one to make sure it matched. That takes work, system resources, and some understanding of how to resolve dependencies. It's especially tricky when several packages will all satisfy the same dependencies. (Don't get me *STARTED* on JDK mismatches!!!!) And it's doubtless how those Scientific Linux "libtalloc" discrepancies crept in.