Fedora Core 5 Status

[Roland McGrath]

> I see, I misinterpreted the fact that all packages have a last modification 
> date of March 6 or after, it is true that most carry the same name as in 
> test3. Most of them have therefore been touch'ed and not rebuild, right ?

There is only one build ever done with the same N-V-R.ARCH.  The files may
have been signed later, or signed again with different keys at different
times; that is the only reason two copies N-V-R.ARCH.rpm should not be
identical.  They are copied around frequently to make up the install trees
and download areas and so forth, which might change the modtimes unrelated
to anything meaningful.

> And since packages based on gcc-4.1.0 and glibc-2.4 stable were indeed
> rebuilt after test 3, it means that most packages on FC5 will have been
> built with an earlier gcc/glibc (pre-release), different from that
> distributed in the release.
> 
> As a consequence, if one takes an FC5 SRPM and does a 'rpmbuild -bb', the
> rpm may contain differences from the native RPM disributed with FC5.

This is potentially true by definition (obviously), when any rpm predates
the prerequisites involved in building it.  (Note that there are always
byte-level differences in a package when you rebuild it even using exactly
identical prerequisites, because of dates and such.  Inside individual
compiled files, there may be byte-level differences inside for the same
reason, though off hand I would expect those to show up only in the
-debuginfo rpms.  You have to do somewhat savvy comparisons to avoid false
mismatches, using tools like eu-elfcmp.)

We honestly don't expect you to find such differences however.  During the
pre-release period, we endeavor to rebuild things when they are affected by
tools changes.  This is why we had those complete rebuilds during testing,
where every package's release number changed.  Just recently, we discovered
a last-minute compiler problem and updated the compiler to fix it; that
problem affected only a few packages (ones producing ppc32 binaries that
use TLS in a certain way), and so we rebuilt all those packages with the
fixed compiler.  We cannot be 110% sure that the new compiler doesn't
differ in some other way beyond our imaginings, or that we didn't overlook
some individual packages that should have been rebuilt--but we are 99% sure.
It's certainly undesireable to make any material change to the compiler so
late, and we would not have done it if it were avoidable.  

But you asked about the updates after the official GNU releases of
gcc-4.1.0 and glibc-2.4, in particular.  These are both much less eventful
updates than you might imagine.  It's not like we rebased to a new upstream
version of the code at the last minute.  For a long time we have been using
a gcc and a glibc based on the day to day upstream branches in preparation
for the 4.1 and 2.4 releases--every update during the testing period has
gotten our base as close as is physically possible to what those releases
would contain when finalized.  The gcc-4.1.0 and glibc-2.4 releases were
essentially blessings of the code we had built already, not new bases for
our builds.  The version numbers changed and very little else.


Thanks,
Roland