Mass rebuilds

[Axel Thimm]

On Sat, Dec 09, 2006 at 07:13:16PM +0100, Thorsten Leemhuis wrote:
> Axel Thimm schrieb:
> > On Sat, Dec 09, 2006 at 12:06:58PM -0500, Jesse Keating wrote:
> >> On Saturday 09 December 2006 11:55, Axel Thimm wrote:
> >>> That would had been some packages too much (e.g. all non-python
> >>> packages), but who really cares about bandwidth and rawhide.
> >> Some?  There would have been a huge number of spurious rebuilds.
> > So? Other than some CPU cycles wasted who would get hurt? 
> 
> Depends on how many packages we would use this scheme for. But I suspect
> that in a lot of cases users that will update to the next stable release
> (e.g. from FC6 to FC7 (or whatever it will be called) in this case)
> won't like package updates just for the sake of rebuilding

But let's face reality: For example how many packages survived w/o a
rebuild from FC5 to FC6 in extras? 29! That's less that 0.5% of the
whole repo. And note that only packages with a disttag would had been
rebuilt anyway, so the whole point does not apply. E.g. any package
with %{?dist} in the release will have to be rebuilt at some time from
FC5->FC6 or FC6->FC7 anyhow.

So regular non-rawhide users are really not affected at all.

> Yes, we did a lot of mass-rebuilds in for the last releases, but I hope
> we in the future now and then have a release that can be realized
> without mass-rebuilds.

But we want mass rebuilds. python 2.6 will also come one day, new
glibc/gcc improvements as well. An improved set of %{optflags} and so
on.

In fact mass rebuilds and a proper way to manage them are *something
good*! And the disttag trick with fc6.89, fc6.89.1 etc is a very KISS
implementation of doing sane and mostly unattended mass-rebuilds.

From a QA POV you would like mass rebuilds for at least every test
release to comb away bugs from forgotten/missed rebuilds and to allow
early surfacing of new bugs.

> > In fact frequent mass rebuilds would disclose bugs that have gone
> > by unnoticed, e.g. when a package's direct or indirect build
> > dependencies change and the maintainer missed to notice that it
> > affects his package indeed.
> 
> Agreed, but we could simply build them to a scratch repo that never gets
> pushed. Tata, we have a similar effect without disturbing users.

Some bugs are found at build-time, others at run-time. No one will test
a scratch repo.

> >[...]
> > The point is: Keep the given man power of contributors to being
> > creative, therefore automate as much a possible.
> 
> Agreed. Thus I think we should work towards something like this:
> 
> "If the maintainer of foo updates foo to a newer version with a
> different API/ABI then he should request rebuilds of all packages that
> this update might break."

But how is that different from the current situation? What you suggest
is OK as a heads-up, but doesn't cut on the time expenses of both the
maintainer of the base package, as well as the maintainers of
dependent packages.

For example the python upgrade was properly announced, and no one is
surpised that python packages are now broken, but we're still having
this discussion about *manual* mass rebuilds being a PITA.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061209/66cfbf3c/attachment.sig>