RFC: Mass rebuild of Fedora Extras before FC5 and how to handle orphaned packges for FC5

[Ralf Corsepius]

On Mon, 2006-01-16 at 00:55 +0100, Michael Schwendt wrote:
> On Sun, 15 Jan 2006 19:59:20 +0100, Thorsten Leemhuis wrote:
> 
> > We probably will have to do a rebuild of all (most?) packages in Fedora
> > Extras before FC5 is released. Why? Some reasons:
> > 
> > - Fedora Core 5 will ship with a new major version of gcc (4.1 in FC5
> > versus FC4 with 4.0).
> > - The new gcc has some enhanced security features that of course only
> > work if applications are compiled with it
> > - The new gcc and the modular X.org might break the compile of some
> > packages. Most things probably can be fixed easily if we do it now. If
> > we wait longer it might happen that other changes occur that break the
> > build in other fancy ways. That would complicate fixing a lot.
> > - rebuilding packages might expose some bugs in gcc or modular X.org
> > that can then maybe can be fixed before the release of FC5
> 
> One by one, please. We need coordination with Core, so we really know when
> GCC is considered "ready enough", so we could start doing rebuilds.
FWIW, to me, the impact of modular X had been way more severe than that
of GCC-4.1.

> Those packagers, who track Rawhide or FC Test releases, possibly have
> verified already whether their packages need fixes for broken C/C++ code
> or changes that come with modular X.
> 
> > Or just sort by name and search for the string "fc4" and look for
> > packages, were no newer version with fc5 in the name is around. I found
> > Macaulay2, SIMVoleon, cfs, cyrus-imapd, gnome-blog and stopped at that
> > point. Those were never rebuild since the release of fc4. 
> 
> Most likely due to lack of policy or a roadmap.
Speaking as maintainer of SIMVoleon, I can tell you why I haven't
rebuilt it yet:

* Initially, there had not been any need to rebuild it. If I hadn't used
%{?dist}, you wouldn't even know this package had been built for fc4 and
it would remain functional until an incompatibility hits.

* Later, modular X11 detonated in Rawhide and broke srpm/rpm
dependencies of SIMVoleon and its dependencies, both in Core and Extras.
Esp. getting the broken packages in Core fixed was a true PITA had
caused major delays in fixing the packages in Extras.

* Midst all this, GCC-4.1 dropped into Rawhide, breaking source code
compatibility (SIMVoleon is C++).

I.e. in a nutshell: So far, Rawhide has been too volatile to me to make
rebuilding SIMVoleon feasible.

Ralf