[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian doesn't have to be slower than time.



On Mon, Feb 18, 2002 at 09:47:23AM +0100, Peter Makholm wrote:

> Matt Zimmerman <mdz@debian.org> writes:
> 
> > How exactly is this different from a buildd, other than that (presumably) it
> > would also build architecture-independent packages?
> 
> It looks like Junichi found a lot of bugs excatly on this account.

That's because he built arch-independent packages (which I mentioned above).
The packages had obviously been successfully built arch-dep-only, or they
would not exist for all but one architecture, and I know for certain that
many of the packages which received bugs were successfully being autobuilt.

> Just building everything wouldn't be an end of all problems solution. It
> would solve some problems with people not upgrading to the latest version
> of a library in a resonable time. It would make it a lot easier to make
> ABI-changes in the distribution.

Maybe, but even if all officially distributed packages are recompiled with
the new ABI, the old one must be supported for at least one release to avoid
breaking other (local) software.  So this doesn't save any work in the
migration department, but it does make things internally consistent.

> It would take a lot of work reading log-files. The question is wether the
> work is worth it. I'm not sure we can find out in any other way than to
> try it. (Well we could discuss some more until some side gives up - The
> Debian Way? (Is that what they mean by rough consensus))

No, "The Debian Way" and "rough consensus" mean that we argue until somebody
sits down and builds something that works.

> > Regardless, I don't think that simple recompiles of packages are what is
> > causing Debian to release slowly.  Woody certainly isn't waiting on
> > recompiles.
> 
> You're right. Complete recompiles wouldn't help woody on this stage. But
> with automatic recompiles we might have been able to release with the same
> gcc on all architechtures, the perl-updates during the development cycles
> could have been almost automatic, and some source bugs might have been
> discovered soner.

Even if it were possible to ship with the same gcc on all architectures, it
might not be the right choice.  If I'm not mistaken, one of the primary
reasons for having different gcc versions is to have the least broken
compiler for each architecture.

I'm all in favour of discovering source bugs, but the autobuilders seem to
do a fine job of that.  The only area where I think this would help is for
packages which are very rarely updated (and so, not built very often).

-- 
 - mdz



Reply to: