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

Re: Managing changes to configure.in as patches

On Fri, Jan 09, 2004 at 12:27:22AM -0500, Joey Hess wrote:

> Matt Zimmerman wrote:
> > If autoconf is run ahead of time, things only break if _all_ of the
> > following are true:
> > 
> > 1. The user is performing a custom build
> > 
> > 2. The user needs to modify configure.ac, Makefile.am, etc.
> > 
> > 3. autotools have broken themselves since the last time the maintainer ran
> > autoconf, automake, etc.
> > 
> > On the other hand, if autoconf is run as part of the build process, then
> > things break if the autotools have broken themselves since the last time the
> > package was autobuilt, regardless of any other conditions.
> > 
> > I think that the former is preferable.
> I much prefer to find out that something is broken now, when I can fix
> it, than to find out that it's broken 6 months down the road when it's
> been shipped broken on CDs everywhere as part of a stable Debian
> release, and cannot be changed.

But it doesn't tell you that it's broken now; it only catches a particular
case.  It's still quite possible for your package to silently break,
especially if it isn't built for a while.  Even if it frequently has new
revisions, it's also quite possible for it to end up in stable, on CDs, etc.
where there is a different version of autotools which will break it
(different from the one used to build it).  That breakage hides until, for
example, someone tries to autobuild a security update for the package, and
then has to clean up the mess.

I think that the "lurking breakage" factor is much worse for packages which
run autoconf during the build than those which run it ahead of time.

 - mdz

Reply to: