On Tue, Apr 10, 2007 at 10:41:53AM -0400, Jeremy Katz wrote:
On Tue, 2007-04-10 at 15:33 +0200, Axel Thimm wrote:
> Just looking at what hasn't been requilt: Some packages like
> bitstream-fonts really don't deserve a rebuild (they also don't
> deserve a disttag FWIW), but others like bridge-utils that depend on
> kernel-headers at build time possibly do, and now we're running with
> bridge-utils built against 2.6.18.
But see, just rebuilding bridge-utils isn't going to be enough to get
any new kernel functionality[1]... you also going to want to get the new
release of bridge-utils. And go through any bugs filed.
I'm not after *new* functionality, I'm afraid bridge-utils build on
possibly deprecated functionality. Maybe bridge-utils requires some
love, maybe not, we won't know until someone either review the case or
does a rebuild.
Automated rebuilds tend to hide things like this, which actually
lead to more problems down the line
Jeremy
[1] I don't know if there actually _is_ any in this case, but there is a
new bridge-utils upstream release from a quick look at the website.
That was just an example, I only looked `till the letter "b" and found
bitstream and bridge-utils as two opposite examples (one not worth of
rebuilds, one the probably is).
The point I want to make is that it is easier to do the rebuild and
see if something breaks while building and/or running it, than to let
it degrade in time and be bitten by it when you least expect it.
I don't think automated rebuild would hide any issues, in fact on the
contrary, they would expose any issues in our faces, *IFF* the get
committed into rawhide proper.
That's why I think that the test release tagged "frozen" should be a
complete rebuild.
--
Axel.Thimm at
ATrpms.net