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

[Michael Schwendt]

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.

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. I'm aware that some
packagers don't know whether they are supposed to update "devel", too, for
every update they publish for FC-4 and older even if they cannot (or do
not) test for it prior to release of FC-5.

There's also the possibility that due to rumours about an automated
mass-rebuild many packagers believe they don't need to do it themselves,
ever. And of course, quite some packagers don't use Rawhide or not even
test releases.

> And we need some scripts that automate the process! Has anyone something
> that can do that on the hard drive already? It should do something like
> this:
> 
> a) increase release of all or some (see next point) package in cvs by
> one. Add changelog entry.
> b) request build of 10 packages (those that weren't rebuild for a long
> time first, the others later). 
> c) wait for the buildsys to finish those 10. That gives a chance for
> other packagers to have access to the buildsys (to build for other dists
> -- otherwise it might take to long until important security updates get
> build)
> d) Go back to b) [or a, depending on implementation of a) and b) ]

... and possibly in dependency order, where necessary.

Hence I think it would be best if packagers got informed when they should
start doing rebuilds. Package maintainers ought to get a feeling about
what other packages in Extras depend on their packages, anyway. That
knowledge is necessary for ordinary updates/upgrades, too, if they
want to avoid breaking dependencies. Coordination could be done via
bugzilla tickets or -maintainers list.
 
> And what do we do with orphaned packages
> ( http://www.fedoraproject.org/wiki/Extras/OrphanedPackages ) ? Drop
> them now? Rebuild them and ship them if they build? Who fixes those that
> did not build? Or do we drop those until someone steps up to fix them? 
> 
> Who files bug reports for those packages that did not build and keeps
> bugzilla in shape? We need new tracker bugs for Fedora Extras 5 just as
> we had them for FE4:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157183 (FE4Target)
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157553 (FE4Target-x86_64)
> (was there one specific to FE4 and PPC? Can't remember)

FE5Target is available for quite a long time already. I've been adding
tickets to it while perusing open bug reports in bugzilla from time to
time (highest bug number visited so far is #172794).

> And what do we do with orphaned packages?

Kick them. Unless they have been touched by an active FE contributor post
FC-4. There have been a few packages already, which do rebuild, but don't
work or don't even install without errors. We do the community a disservice
if we offer packages, which bear the risk of either being out-of-date or
not-working.