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

Re: Proposed Autoconf 2.50 path

On Fri, May 25, 2001 at 10:48:42PM -0400, Ben Pfaff wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > I would suggest instead having autoconf2.13 either use alternatives
> > or diversions to provide an "autoconf" binary, and arranging something
> > special with autobuilders so that these packages can continue to build.
> Any suggestion about mechanism on that?
> Alternatives and diversions aren't a very good way to do this,
> IMO, because some packages will need one version, some another,
> and you don't want to change an alternative between package
> builds (and what if you build multiple packages in parallel?).

That's not that much of a problem: autobuilders don't do parallel builds,
and are quite capable of installing or removing packages in their chroots
between builds.

> Okay, here's another idea: when plain `autoconf' is run, choose
> one of autoconf2.13 or autoconf2.50, dynamically based on roughly
> the following criteria:

Extending this slightly:

	autoconf.deb includes /usr/bin/autoconf as autoconf 2.50

	autconf2.13.deb depends: on autoconf.deb, diverts /usr/bin/autconf
		in preinst to /usr/bin/autoconf2.50, includes
		/usr/bin/autoconf2.13 and includes /usr/bin/autoconf as
		your clever little script

> 	* If `configure.ac' is present, or AC_PREREQ (2.50) or
>           higher is requested within configure.in, use
>           automake2.50.  (configure.ac is a new name for
>           configure.in not supported by 2.13, and it is now the
>           preferred name.)
> 	* Otherwise, use autoconf2.13.

If this can be done, it sounds good.

> I am not entirely happy with this, because it does not encourage
> making packages compatible with Autoconf 2.50, but it is fully
> backward-compatible AFAIK.

There are at least three things encouraging conversion here: (1) it's
the Right Thing To Do, (2) just installing autoconf (or just doing an
upgrade) will break their packages when they try to build them, (3)
you'll probably be removing autoconf2.13 from the archive in the near
future (ie, after woody's released).

AIUI, this means:

	(1) you need some .deb you can install that'll let you build
	    debs that aren't compatible with autoconf 2.50

	(2) you need a list of all the packages which need this special

	(3) this list needs to be passed on to one of the people with
	    access to the source dep override list, who needs to adjust
	    that list appropriately

As part of (2), filing normal bugs against the packages with hints as to
how to make them work would be great.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpKiCMJMgTAJ.pgp
Description: PGP signature

Reply to: