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

Re: autotools during build

On Sat, Aug 13, 2005 at 01:13:11PM +0200, Armin Berres wrote:
> Steve Langasek wrote:
> > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
> > If you rerun autoconf/automake/libtool at package build-time, when you don't
> > need to, what you get are large diffs against upstream every time a new
> > version of the autotools becomes available.  Aside from wasting (a little)
> > space in the archive, that makes it harder for NMUers or passing developers
> > to see what's going on in your package.

> > The autotools-dev README.Debian is a good guide to these issues.

> >From autotools-dev Readme.Debian:

> "You have two good choices, and one bad choice for packaging upstream
> source which uses automake and autoconf and contains generated files:

> 1. Tolerate the big diff size, and run the autotools stuff before you
> create the debian source package.  This is what I usually do.

> 2. Patch the autotools files (*.in, *.am) at build time, make sure all
>     the build dependencies are 100% correct (hint: conflicting with
> autoconf2.13 is *always* a good idea if you're not using autoconf 2.13
> and automake 1.4).  This means that the autobuilders will have to rerun
> the entire thing, and so will the users, etc.
> When you're doing a full dpatch-based packaging, this choice makes
> sense.

> 3. Live with whatever crap upstream used.  You do *not* have this choice
> if libtool is being used, BTW.  And it is a bad choice IMHO, I'm yet to
> see any distribution with better autoconf, automake, libtool and gettext
> packages than Debian (and I do have a lot of experience on this)."

> Most people proposed to use the 3. choice so far. According to above
> document this is not a very good solution.

Apparently.  Ohwell, I'll defer to the autotools-dev maintainer, then,
though I do stand by my comments about big diffs making it hard for third
parties to know what's going on.  I think Joey Hess's recommendation is the
best of all, here.

Though fwiw, build-conflicting with autoconf2.13 seems like overkill when
one can just use AC_PREREQ([2.50]) in the configure.in.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: