[Fedora-packaging] Re: Full repo rebuilds

[Axel Thimm]

On Tue, Apr 10, 2007 at 10:41:07AM -0400, Jesse Keating wrote:
> On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote:
> > 1 100%
> > 2 99.7%
> > 3 100%
> > 4 96.6%
> > 5 99.991%
> > 6 95%
> > 7 80%
> >
> > So as you see, up to F7 Core had really been effectively rebuilt on
> > each release with FC4 and FC5 being the most "sloppy" ones leaving
> > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild
> > rate. This *is* a new release model.
> 
> What I'm saying is that these numbers often happen naturally instead of forced 
> by a full rebuild.  _That_ is the model that hasn't changed.

OK, still the packages were all more or less rebuilt, and sometimes
the packagers comment this as a simple rebuild for the upcoming
release. Which means that while there was no mass-rebuild, many
packagers in RH decided to do so on their own when the time came.

For F7 the policy obviously changed, otherwise there wouldn't be a
sudden drop from 95-100% to 80%.

> The ONLY time we've done a forced rebuild is for technical reasons
> and NOT for arbitrary reasons like "hrm, this is test2, maybe we
> should rebuild everything just for the hell of it" or "there is a
> lot of disttags that haven't been updated, lets do rebuilds to reset
> them, that sounds like a good idea...".

Forget about the disttags, the discussion started about them, but this
is not about cosmetics. They only indicate the problem which is that
some packages have not been rebuilt. I'm personally against rebuilding
just for the fun of nice disttags.

But I'm all for rebuilding where it makes a technical difference. Some
userland utils depend on kernel-headers, that has changed and in doubt
all such dependent packages would require rebuilds or a
review. Furthermore glibc has changed in various places among other
some sys/personality stuff and kernel 2.4->2.6 bits. Any package that
required 2.4 compatibility in this area is now busted (don't remember
whether it was sys/personality or something else, check the diff). And
who's going to check which packages where using these glibc headers to
enforce a per-package rebuild?

And this is just the surface scratched. If someone invests more time,
he will come up with more dependencies that may now be broken or not,
and finding that out takes more developers' time than a simple
rebuild-all-and-test-the-outcome model.

> Rebuilding for technical reasons is fine, relying upon throwaway
> rebuilds to find said technical reasons is strongly encouraged.

Ask yourself why they are being thrown away. If there really is no
technical reason to rebuild a package, then the rebuilt package can't
be broken or less stable that the "old" one. By throwing them away you
never have the chance to actually have them tested by a wider audience
(or any audience at all). Placing the rebuilds into rawhide instead
will really show whether the rebuild was worth it or not, e.g. when
things start to break, and you get a change in fixing them.

Now we will only get that chance when a package is rebuilt for other
reasons post-release, e.g. while adding a security fix. And imagine
the confusion of the packager that only changed one line in
foo-1.2-3.fc6, successfully rebuilt it to foo-1.2-4.fc7, and the
package does not run. Because that scenarion will happen, Matt checks
for build errors, so the build will succeed, but the more intricate
runtime bugs will only surface when you have the least time to deal
with them. And the horror scenario is that since it was a one-liner
fix it will get less testing and make it into updates-released being
half-broken giving Fedora negative publicity.

In short: It's better to have these packages break and fix them during
the development/testing cycle than during maintenance.

> Picking arbitrary points to forcefully rebuild everything is not.

Not an arbitrary point, but at "freeze time" (personally I would
rebuild for each test release, but rebuilding once at freeze time
would be enough).

And again: This has nothing to do with rectifying disttags and
cosmetics in the package name, they are for now just an easy metric to
see what was rebuilt, and when. And if we'd decide to go for full
rebuilds, disttags would be a tool to get 98% done w/o a sweat. But
still they are not the problem, they might become the solution
instead.
-- 
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-packaging/attachments/20070410/8e244de6/attachment.sig>