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

Thorsten Leemhuis fedora at leemhuis.info
Mon Jan 16 15:40:12 UTC 2006


Am Montag, den 16.01.2006, 00:55 +0100 schrieb 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
>[...]
> 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.

Hopefully. But how many are that? 

> > 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.

Then we should have one for the future. 

> 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.

Exactly. 

> > 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. 

Yeah, maybe. But we have only four weeks from test3 to final. A "get
your packages rebuild now" would probably take at least a week until
everything is build. 

The buildsys will probably be blocked because it is flood by
uncoordinated builds -- no chance for building important security fixes
for older dists. 

After that week we could try to rebuild those packages where no one
requested builds. Or do we want to drop those packages, too?

> 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 

/me fears the overhead of that, 

> or -maintainers list.

Sounds better.
 
> > 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.

That okay for everybody? Or are there people around that want to build a
orphaned-packages-task-force that looks at the stuff?

-- 
Thorsten Leemhuis <fedora at leemhuis.info>




More information about the fedora-extras-list mailing list