On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote:
> o The choice of what to rebuild or not requires more developer time
> than fixing broken rebuilds: Currently some heuristics were uses to
> cherry-pick what to rebuild. This requires a careful examination
> that if doen properly consumes as much or more developer time than
> to fix any broken rebuilds. If not done careful, then some
> dependencies will be missed. For example the current upgrade sees
> the following changes in the buildtools
>
> FC6 F7
> gcc 4.1.1-30 4.1.2-8
> glibc 2.5-3 2.5.90-20
> binutils 2.17.50.0.3-6 2.17.50.0.12-3
>
> Perhaps the gcc or binutils changes are not that big, but the glibc
> ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking
> the API (the glibc-headers) gives:
>
> 41 files changed, 297 insertions(+), 220 deletions(-)
Even the glibc changes in F7 are mostly glibc internal changes, bugfixes
and addition of a few new symbols (epoll_wait, sync_file_range,
strerror_l, __sched_cpucount) and only on PPC a new version for existing
symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc
changes necessitate a mass rebuild (and I'm not aware of any huge changes
in redhat-rpm-config either) at this time and that's why F7 rebuild status
is so low. GCC 4.2 has been stagnating for 6 months now and we have
several important things backported anyway in GCC 4.1.x-RH (OpenMP,
visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
...). If gcc, binutils or glibc changes substantially in say F8, we'll
of course need to do a mass rebuild.
I'd note that sometimes it makes sense to rebuild all packages, including
noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config
etc. changes that affect all packages.
Jakub
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
