Bug#746514: Autoreconf during build

[Charles Plessy <plessy@debian.org>]

> >> Le Thu, Jul 10, 2014 at 04:46:53PM +0200, Bill Allombert a écrit :
> >> > +   <p>
> >> > +          If your package includes the scripts <prgn>config.sub</prgn> and
> >> > +          <prgn>config.guess</prgn>, you should arrange for the versions
> >> > +          provided by the package <package>autotools-dev</package> be used
> >> > +          instead (see <package>autotools-dev</package> documentation for
> >> > +          details how to achieve that).

> > On Sat, Jul 12, 2014 at 09:42:23AM +0900, Charles Plessy wrote:
> >>
> >> I agree with the intent, but I think that the wording is too restrictive, since
> >> a package that would use autoreconf and install config.* files at a version
> >> newer than what autotools-dev provides would not comply with the Policy.

> On 12 July 2014 19:50, Bill Allombert <ballombe@debian.org> wrote:
> >
> > This was intentional: this allow porters to update config.sub and config.guess
> > in autotools-dev and not have to update all the automake versions.

Le Sat, Jul 12, 2014 at 08:24:25PM +0100, Dimitri John Ledkov a écrit :
> 
> I thought autoreconf / dh-autoreconf install the versions provided by
> autotools-dev on Debian systems. If that's not the case, we should fix
> it.

Hi Bill, Dimitry, and everybody,

I looked at the autoconf and autotools-dev packages:

 - The autoconf packages depend on autotools-dev and replace their config.sub and
   config.guess files by the ones provided by autotools-dev, using symbolic links.

 - The documentation in the autotools-dev package recommends as best practice
   to run autoreconf, and discourages the other options.

Altogether, the wording was not restrictive as I thought.

Nevertheless, what would people think of adding a bit more explanation on the
purpose of replacing these files ?  Not all readers will have
/usr/share/doc/autotools-dev/README.Debian.gz available on their computer.  How
about the following addition or an equivalent?

    "This ensures that these files can be updated distribution-wide when introducing
    new architectures."

Also, adding "at build time" somewhere may clarify that patching these files is not
a good solution.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan