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: