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
treatment
(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.
Cheers,
aj
--
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:
pgpwP5q25EFVy.pgp
Description: PGP signature